[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
how to realize a medium coupled build environment?
Marc van Woerkom
how to realize a medium coupled build environment?
Tue, 21 Nov 2000 17:24:41 +0100 (CET)
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:
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
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
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
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
This is the typical build infrastructure used in case of different developer
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
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.
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.
(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
What do you folks think?
- how to realize a medium coupled build environment?,
Marc van Woerkom <=