Re: build dependencies



+++ Robert Bihlmeyer <robbe@orcus.priv.at> (Robbe) writes:

 Jonathan> Something like a file in each module called .build-deps
 Jonathan> with module-name: other-module other-module other-module

 Jonathan> Just build ordering dependencies, not run-time
 Jonathan> dependencies, else you end up running in circles.

Robbe> Why not use the cvs module system for that? I.e. for each module
Robbe> foo having dependencies, you define a new alias foo-dep that lists its 
Robbe> dependencies. For example, you'd put the following line into the
Robbe> modules file:

Robbe> gnome-games-dep -a gnome-core-dep gnome-core gnome-objc-dep \
Robbe> 	gnome-objc gnome-guile-dep gnome-guile

Robbe> That means that gnome-games depends on gnome-{core,objc,guile} plus -
Robbe> recursively - their dependencies.

Robbe> If checking out gnome-games, I issue "cvs co gnome-games" as usual.
Robbe> Whenever I want to check out all things needed to build gnome-games, I
Robbe> do "cvs co gnome-games-dep gnome-games".

Robbe> Building a graphic representation of the tree by analyzing this file
Robbe> also seems quit easy.


Doesn't this get you gnome-games-dep/gnome-objc, gnome-games-dep/gtk+, 
and so forth (or does the -a make that not happen)?  I'm rusty on
my CVS, it's been a while since I've done anything other than 
anonymous.

I think it would make sense to make the -dep targets include the 
modules themselves to make it a bit less verbose.

I think you also may end up checking things out twice if they are
listed more than once.  Or maybe CVS is smart enough to uniquify the
list.  I wouldn't be surprised if this would make it go try to update
gtk+ about 10 times though.

The other problem here is that you have to go ask the CVS server for
the modules file again and again in order to do this in an automated
fashion for a ``build of the system''.  You can get CVSROOT too I 
suppose, but that shouldn't be necessary.  At that point, you might
as well have a file "gnome-build/foo" instead of "CVSROOT/modules".

I think putting files into the individual module directories would be 
a better thing.  The files wouldn't get put into 'make dist' 
distributions.

It would be nice to have the recursive checkout capability, regardless,
but I think making a build system off of that would be suboptimal.

It's probably possible to use sed and tsort to take the lists in 
either form and come up with a list that is the order in which the
modules should be compiled and installed.


-- 
Jonathan Sergent / sergent@io.com



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]