Re: use of modules, static vs shared, and dependencies

[Howard Chu]

Ralf Wildenhues wrote:
> Issue: When linked statically, a module needs to be built before its
> encompassing library.  OTOH, if built dynamically, it needs the library
> to link against it.  This is currently solved by reordering SUBDIRS
> during configure.  Obviously, this limits the source tree structure, and
> the chance to eliminate many Makefile.am's in favor of non-recursive
> builds.
>
> Can we do better than this in any way with the features in CVS HEAD?
> When using preopened modules, do we provide for this kind of setup at
> all?  Portably for all kinds of systems?
>
> Should I draw a diagram?
> (yes, I know, it should be a test case.. did I mention it's large?)

We have this situation in OpenLDAP slapd, since a number of modules can 
be built either statically (linked into the slapd executable) or 
dynamically (loaded by libltdl), and several of the modules depend on 
each other in addition to the main slapd executable and the 
libldap/liblber libraries (which may be static or dynamic). In this 
case, each module's compilation is controlled by a three way --enable 
switch at configure time: no (don't build), yes (static), mod (dynamic). 
The list of static and dynamic modules go into two separate Makefile 
macros. The slapd Makefile compiles all static modules, the slapd 
executable, and then all dynamic modules, three separate steps. There 
are appropriate dummies in case either of those two macros is empty, e.g.:

prog: slapd $(SLAPD_DYNAMIC_STUFF)

dummy1 $(SLAPD_STATIC_STUFF):
        blah blah blah

slapd: $(SLAPD_STATIC_STUFF)
        blah blah blah

dummy2 $(SLAPD_DYNAMIC_STUFF): slapd
        blah blah blah

--
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  OpenLDAP Core Team            http://www.openldap.org/project/