automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

build order of `make' and template libs


From: Ralf Wildenhues
Subject: build order of `make' and template libs
Date: Thu, 28 Apr 2005 08:41:35 +0200
User-agent: Mutt/1.4.1i

[ sorry for the cross-post, this concerns both tools ]

SUSv3 states that `make' should update prerequisites to a target in the
order in which they are given.  However, I cannot find any reference to
whether the resulting tree of out-of-date targets is traversed
depth-first or breadth-first.  Do `make' implementations differ in this
respect, i.e., do any work breadth-first?

Example makefile:
all: lib1.la lib2.la
        @echo make $@
lib1.la: a.o b.o
        @echo make $@
lib2.la: c.o
        @echo make $@
a.o:
        @echo make $@
b.o:
        @echo make $@
c.o:
        @echo make $@


Background:
In order to build C++ libraries with templates and some non-GNU
compilers, it might be necessary to store template instantiations (and
other files, possibly) in/with the created library.  Compilers usually
generate these in some pre-specified template directory.  However, not
all compilers are smart enough to be able to recreate these objects at
library link time, so we may not just delete them before linking and
call the prelinker again.  OTOH, it will be fatal to include extra
objects into a library which do not belong there at all.

Now, the idea was to remove all template instantiations _after_ creating
a library.  This can only work if make works in depth-first order.
Surely this idea means quite a few limitations for both the library
author and the end user:
- no object needing template instantiations may end up in more than
  one library or executable.
- no parallel make.

The other idea to solve this would require finding out the exact list of
template instantiation object file names necessary for the library,
which would resolve both above limitations, but might be a great deal
more work to implement in Libtool (and more intimate knowledge of the
compiler).

Another idea would be the use of per-library (and per-program) template
directories.  Something like the per-target flags mechanism could
trigger those, I believe.  In any case, libtool would need to know
something about the output name at source file compilation time, as
opposed to only at link time.

As it seems, a number of compilers will still not be able to produce
libs, even convenience archives, as often the prelinking mechanism is
not sophisticated enough for this kind of procedure.  But that remains
to be seen.

Thoughts?

Thanks,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]