how to realize a medium coupled build environment?

[Marc van Woerkom]

Hi!

I would need some input (or perhaps you know some existing example) on 
how to set up what I would like to call a "medium coupled build environment" 
due to the lack of a better name.

In my present view, the autotools provide either a "strong coupled" or a 
"weak coupled build environment" regarding sub projects. 
Alas it seems I need something inbetween.

What do I mean with that?


1. strong coupled modules

This is what typically goes into a project tarball.

Having some directory structure like this one:

  game/
    Makefile.am
    config/
    configure.in
    src/
    snd/
    www/

where we have central Makefile.am and configure.in files, the sources 
to eg a game in directory src/, and the sources to a sound library in 
sound/, and some web related code in www/.

So we have three modules (1 app, 2 libs) or subprojects.

The interesting bit about this is, that there is one configuration and 
Makefile generation step for the whole package.

Especially make dependencies are generated among modules.

If we change a line in www/foo.c and try to compile within the src/ 
subdirectory, the change in www/foo.c will be noticed and that source 
recompiled before compilation of stuff in src/ starts. 
This way I can change stuff in all module subdirectories, and still risk 
no getting out of sync (linking an outdated library/objects into the 
main app).

This project setup is typically used by a developer group that works 
on one package, ranging from small GNU hello to godzilla sized mozilla.


2. weak coupled modules

That kind of interaction is used by packages installed on a system.

A game for X11 would use the GUI via header files and libraries installed 
in certain standard locations like /usr/X11R6/include and /usr/X11R6/lib.

This is a rather loose coupling. 

Either some headerfile foo.h is there or not. 

With libraries, access is bit more fine tuned, via some library version 
naming scheme (eg libfoo.so.x.y.z under Linux or just libfoo.so.x under 
FreeBSD).

Returning to the example scenario from above this would mean that we 
could have three indvidual source trees for that game, its sound and web 
libraries:

  game/
    Makefile.am
    config/
    configure.in
    src/

  snd/
    Makefile.am
    config/
    configure.in
    src/

  www/
    Makefile.am
    config/
    configure.in
    src/

Now, if www/src/foo.c was touched, and one would compile in game/src, 
there would be no automatic recompilation of the www/ project prior to 
the compilation of src/.

What would be possible is, that the configure script in game checks for 
an libwww of a certain version installed in /usr/local/lib (or some other 
predefined system wide library location) and stops if is not there.

Or some outer package management system, like FreeBSD's ports collection, 
would know what libraries are required to generate the game project, and 
thus fetches, configures, compiles and installs the libwww if the proper 
version has not been installed on the system.

Again, getting out of sync between game/ and www/ is prevented, to a 
certain degree at least. 

While in the strong coupled case a simple change would force recompilation, 
now the only change dramatic enough is bumping the library versions in  
game/ or accidental deinstallation of libwww in /usr/local/lib
(or similiar).

This is the typical build infrastructure used in case of different developer
groups.


3. medium coupled modules

I got the task to set up the build infrastructure for a large project that
will consist of dozen or so sub projects, with a group of developers working
on that.

Discussing with those guys, I presented traditional scenarios 1. and 2.
What was wanted seems to be something in between.

The loose coupled scenario 2. was liked because of the possibility to
checkout only parts of an eventually large source tree.
While a scenario 1. solution would force one to checkout all modules.

On the other side they still want to have make dependencies among that 
checked out subset of modules.

Tricky.

So what I try right now is another configuration step, something
like a source tree configuration, where parts of a larger tree
will be molded into a simple scenario 1. type project.

The idea was to allow the user checking out only part of the
source tree e.g.


  Makefile.am.in
  bootstrap
  config/
  configure.in.in
  game/
  www/

(note that snd/ has not been checked out)

and then having a bootstrap script inspecting the tree for checked out 
modules, and if that subset makes sense to compile, generates 
Makefile.am and configure.in from templates where e.g. the SUBDIRS variable
is set to 

    SUBDIRS = (standard stuff) game www

in this example case.

The hope is that this can be done in a way, that the resulting generated
configuration script will have the desired dependencies among modules.

Perhaps it is even possible to use automake/autoconf in a way, that
I just list the module list ("game www") in some fill, and only the
traditional one configuration/generation step is needed (and nothing
like another set of templates like configure.in.in is necessary).

I thought other larger projects might use some fine tuning of this
sort, but I have found nothing yet.

Or this medium coupled scenario is bull in some way I have not recognized
yet. :-)

What do you folks think?

Regards,
Marc