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.
Although it is definitely true that kdesrc-build hides what it's doing unless you delve into either the --pretend output or the log files (where the command run is displayed at the top of every log file), this is also a pro: pros: * There is black magic happening behind your back so that users who are unwilling/unable to navigate gcc/make/cmake can still build and test bleeding- edge versions of KDE despite their lack of CLI mastery. Anytime you add a layer to a working system there is usually a pro of "this makes me do less work" and a con of "now I forgot how it works" (e.g. moc, high level programming languages in general, etc.) I certainly don't disagree with the con you mentioned, but I do think that the benefit in increased testing coverage outweighs the concern with "black magic", especially since I take great pains (and have for years) to have kdesrc-build operate as much like you or I would do the build as possible. 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. Regards, - Michael Pyne
signature.asc
Description: This is a digitally signed message part.
