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/
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool