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. Parker
