On Thursday 20 January 2011, Michael Pyne wrote: > 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 ;)
The patch Allan posted, i.e. using <project>_SOURCE/BINARY_DIR instead of CMAKE_SOURCE/BINARY_DIR does not break anything, it only makes project more independent from their location. > 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. Yes, of course. It would/will be only additionally/optionally. > 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. I haven't looked at strigi recently, I still suffer from a git lag ;-) Alex _______________________________________________ Kde-buildsystem mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-buildsystem
