Building multiple source modules

[Michael Pyne]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-buildsystem/attachments/20110120/fface9b7/attachment.sig