(I haven't read the patch yet.)
>>> "MA" == Marc Alff <[EMAIL PROTECTED]> writes:
[...]
MA> A typical "partial link" or "relocatable (-r)" command is :
MA> ld -r -o glued.o part1.o part2.o ... partn.o
I didn't know "ld -r". How portable is it?
MA> As a result, a build chain can be longer :
MA> *.c, *.cpp --> *.o --> * glued.o --> * super-glued.o --> lib*.a, lib*.so
MA> or binaries
Will your proposal allow the creation of *.a, *.so, and
binaries out of relocatable objects? I'm wondering, because the
*.o should be compiled differently if they are meant to be part
of a shared library, and the _RELOCATABLES syntax doesn't
indicate where the object will be used.
MA> The difference between "glued.o" and "libglued.a" is that a
MA> "relocatable" object
MA> contains all the code in one block, with internal link dependencies
MA> already resolved,
Just to make sure I understand: would I get a similar result if
instead of gluing these objects I had compiled the concatenation
of all their sources in a single run of the compiler?
(Consider that question from the point of view of someone who is
used to split static libraries in as much objects as possible so
the linker picks only what it needs and not more.)
[...]
MA> The main concern is that, how the source code is organized into directories
MA> with recursive makefiles is an implementation choice,
MA> it should **not** impact what the final deliverable looks like (maybe I
MA> still want ONE *.a or *.so or binary at the end,
MA> not expose a collection of *.a or *.so to my users).
Of your three points, this is the only one I do not understand.
If you use Libtool convenience libraries you'll have a
collection of *.la in your build tree for all the subparts of
your project, but then you'll gather all these in a big *.la
library which you will install. So the final deliverable is
still one library, not a collection of libraries.
(Example in the "Libtool Convenience Libraries" section of the
Automake manual.)
MA> ============ Part III : Proposed enhancement ============
MA> In short, Makefile.am can be written like this
MA> noinst_RELOCATABLES = glued.o
MA> glued_o_SOURCES = part-1.cpp part-2.cpp
MA> glued.o is a **notation**, not the actual name of a file :
MA> ..._RELOCATABLES = glued.o super-glued.obj
MA> glued_o_... = ...
MA> super-glued_obj_... = ...
s/-/_/
MA> will work both on platforms that use .o or .obj for objects,
MA> and in both cases the generated makefile will contain names like :
MA> glued.$(OBJEXT) : ...
MA> super-glued.$(OBJEXT) : ...
Allowing both extensions in _RELOCATABLES (and hence in the
associated variable names) looks confusing to me. In any way
the resulting objects may not be built as written, so the
extension we write here is just a convention. I'd say let's
offer only syntax.
MA> You can add these if you like :
MA> glued_o_LDR = /my/own/ldr/program
MA> glued_o_LDRFLAGS = -please -make -section blah -start -at -address blah
MA> glued_o_LIBADD = more-part-X.$(OBJEXT) more-part-Y.$(OBJEXT)
(Independently of your patch I'm wondering if Automake should not try
to replace .o by .$(OBJEXT) in LDADD/LIBADD lines.)
MA> The generated Makefile uses LIBTOOL to actually do the linking work,
MA> so it should be portable : $LIBTOOL --mode=link xxx
Where xxx is "ld -r ..."? I'd like to hear from the Libtool
folks about this. Is libtool supposed to emulate "ld -r" or
something if it doesn't work?
My intuition is that if libtool knows how perform "ld -r"
portably then there is an easier way to go:
- libtool's convenience libraries can be used to setup the
kind of hierarchical layout you described, and they can be
used to build static or shared libraries as well as when
linking program
- so I guess all you need is a libtool switch to ask
for a relocatable output.
Then you'd write something like
noinst_LTLIBRARIES = libpart.la
libpart_la_SOURCES = foo.c bar.c
libpart_la_LDFLAGS = -reloadable
bin_PROGRAMS = whatever
whatever_SOURCES = main.c
whatever_LDADD = libpart.la
Does it make any sense?
--
Alexandre Duret-Lutz
Shared books are happy books. http://www.bookcrossing.com/friend/gadl
