On Wednesday, January 19, 2011 15:55:28 Alexander Neundorf wrote: > On Wednesday 19 January 2011, Michael Jansen wrote: > > On Wednesday 19 January 2011 18:57:32 Alexander Neundorf wrote: > > > Hi Allan, > > > > > > On Wednesday 19 January 2011, Allan Sandfeld Jensen wrote: > > > > Hello > > > > > > > > I have recently been worried about the increasing number of modules > > > > KDE is being divided in. Having to checkout, configure and build a > > > > huge amount of individual modules seems to greatly increase the time > > > > it takes for developers to build new test versions of KDE. This is > > > > especially true if you make changes to basic libraries and want a > > > > full KDE installation rebased on the modified libraries. > > > > > > Same here... > > > Great that you started working on a solution ! :-) > > > > What is the problem with tools like > > > > http://kdesrc-build.kde.org > > http://michael-jansen.biz/build-tool > > > > They do even more work for you like automatically updating, configuring > > and building. > > > > I really would like to know what mpyne and i have to do to get you guys > > switching to one of those tools and stop trying to solve those problems > > yourself each time. > > I'd really like to know what I have to do to get you guys try to use and if > necessary extend the tool we are using, CMake, instead of trying to solve > those problems yourself each time ;-)
Well build-tool is more recent, but kdesrc-build is a continuation of a script that has existed since it was called kdecvs-build (and back then it was kdecvs-build because there was already a kde-build!), so the feature set is more than simply building modules in a set order. Among other things, kdesrc-build also logs output to timestamped directories (so you can grep for build errors at your leisure instead of panicking because you forgot to use screen or output to a file), it builds Qt from gitorious.org (and I suppose soon git.kde.org for kde-qt), etc. Honestly, the big reason I use it is so I don't have to remember to set CMAKE_INSTALL_PREFIX and CMAKE_PREFIX_PATH! ;) However, it is nice being able to edit ~/.kdesrc-buildrc as modules move and instantly get gratification instead of waiting for changes to CMakeLists.txt. And of course, the chicken-and-egg problem is how to obtain CMakeLists.txt from Subversion or git in the first place... Either way, I won't evangelize build-tool or kdesrc-build except to say that there is certainly an explosion of git modules happening, and both scripts can help with that. I would welcome CMake magic as well, although I would ask to avoid making builds incompatible with the existing build scripts (and to be clear, I am not the only user of kdesrc-build ;) If you're worried about what that means, don't be: kdesrc-build just runs cmake and make like you'd normally do. If you can keep that working for individual projects *and* their supersets that would be awesome. strigi does /not/ work like that unfortunately: It must be built from the strigi supermodule, which then uses CMake to download and build the rest. That's fine as a one-off, but I really think *requiring* supermodules in order to build submodules is a recipe for a great deal of annoyance if that problem spreads. Regards, - Michael Pyne
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
