Building multiple source modules

[Alexander Neundorf]

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