Initial support for kde_projects.xml in kdesrc-build

Parker Coates parker.coates at
Tue Feb 1 01:38:15 GMT 2011

On Mon, Jan 31, 2011 at 19:08, Michael Pyne wrote:
> On Monday, January 31, 2011 18:19:12 Albert Astals Cid wrote:
>> cons:
>>  * There is black magic happening behind your back and once something
>> breaks you won't know how to fix things by yourself.
> For instance even after using kdesrc-build on my source tree for years I can
> go to svn or git modules and run the standard update command (even git pull)
> and everything just works. I can go to the build directory and run make or
> cmake-gui and things just work. When I'm worried about what kdesrc-build is
> about to do, I can pass the --pretend flag and it shows the command line for
> about 95% of the commands it would run. In short it is (my idea of) a bum-
> standard build system, or as close as I can get it in an automated script.

I was about to make this same point. When I first started KDE
development, I tried to set up my own build environment. After one
unsuccessful attempt and then one somewhat successful attempt, I
learned about kdesvn-build. It got me up and running with trunk after
5 minutes of configuration and a single build run.

While I'm sure I learned some things from my manual setup attempt, I'm
pretty sure that I learned more from having a working build
environment to play around in. And as Michael said, that's the beauty
of kdesrc-build. You are free to play around with your checkouts and
build directories and things will generally keep working. For example,
KDevelop and kdesrc-build will happily share a build directory and
reuse each other's CMake caches. There's certainly value in
understanding the details of the manual guides currently in Techbase,
but honestly I think they'd be easier to learn if one already had a
kdesrc-build setup to work with.


More information about the kde-core-devel mailing list