Re: how to realize a medium coupled build environment?

[Marc van Woerkom]

> What you describe is exactly what KDE uses. 

Yea. Makes perfect sense for such a large project.
Thank you very much for that hint. 

>From the larger open projects I have had a look at Mozilla only 
so far. I will check it.


> We have configure.in.ins in every subdirectory that needs 
> configure checks. 

I suppose that is to generate the AC_OUTPUT list.

The scheme I arrived at lists every thinkable module

    mod1/Makefile
    mod2/Makefile
     .
     .

in the argument list of AC_OUTPUT.

This is ugly because it generates warnings for every module
that has not been checked out at configure time.

Further one has to provide 
    
    --without-FooBar

switches to cut down SUBDIRS internally to the list of 
available modules, otherwise a "make all" will fail.


> The Makefile.cvs you run after checking out creates one 
> configure.in with the used parts and then it all works from 
> there. 

Yes, adding another .in layer for generating configure.in
would have been my next evolution step too.

Together with some scanning of what is there (perhaps every
subdirectory it finds, except certain standard ones) would
make it unnecessary to 

a) provide a list of all possible modules in AC_OUTPUT in advance
b) provide "--with-FooBar" switch logic for all possible modules
   in advance.

On the other hand, the switches solution has the feature,
that I can keep a full tree with lots of modules around,
while telling configure, which ones to use actually.

Otherwise I would have to remove the modules I don't need,
thus I would need to work on a fresh copy for every
different module subset selection. OK, that sort of throw
away tree is quite fitting for cvs based development.


> SUBDIRS are created from the existant subdirs with a Makefile.am, 
> and we also have COMPILE_FIRST and COMPILE_LAST to manipulate the 
> subdirs order in case you need libraries for example

>From what you write that seems to cover build order, makes 
sense because not every project might be built in the lexical
order that their directory names suggest.

You mention library dependency.

I used this construct

    dnl  treat module dependencies

    if ! ${module_base}; then
      if ${module_dataserver}; then 
        AC_MSG_WARN([module Dataserver depends on module Base => Base will be 
used])
        module_base=true;
      elif ${module_dataserver2}; then 
        AC_MSG_WARN([module Dataserver2 depends on module Base => Base will be 
used])
        module_base=true;
      elif ${module_dataserver3}; then 
        AC_MSG_WARN([module Dataserver3 depends on module Base => Base will be 
used])
        module_base=true;
      fi
    fi

to ensure that the build of a Dataserver* module will trigger 
the build of a Base library first.

Again this is ugly, because all dependencies are coded into
configure.in which might grow into large list over time.

In a collection scheme I think it would make sense to 
deposit dependency hint files in the module subdirectories
that tell the module collection phase what modules they
depend on:

    Base/
       ("I need nothing")
    .
    .
    Dataserver2/
       DepHint ("I need Base")
    Dataserver3/
       DepHint ("I need Base")

So that information would not been kept central in one giant
configure.in section but kept distributed.

Regards,
Marc