Greetings,
On Wed, 23 Jul 2003, Alexandre Duret-Lutz wrote:
...much good advice, which I can report on here.
> >>> "Norman" == Norman Gray <[EMAIL PROTECTED]> writes:
>
> Norman> How does one optionally include C++ (or any non-C)
> Norman> sources in automake?
> [...]
> Norman> The obvious thing seems to be to use AC_LIBOBJ([function])
>
> LIBOBJS is primarily intended to help packages build their
> library of replacement functions for missing feature. I think
> it is best avoided otherwise.
That makes sense, and confirms what I'd picked up from the docs.
> Yes. This is one way to compile sources conditionally.
> The `Conditional Sources' node of the manual shows another possibility
> based on Automake conditionals.
I hadn't really examined Automake conditionals, partly because, as you
suggested later, they do seem rather clumsy for the task at hand.
> A third possibility that is really neat when the conditional
> code comes into modules is to declare EXTRA_ libraries.
>
> EXTRA_LIBRARIES = libmodule1.a libmodule2.a libmodule3.a
> libmodule1_a_SOURCES = src1a.c src1b.c src1.h
> libmodule2_a_SOURCES = src2a.c src2b.c src2.h
> libmodule3_a_SOURCES = src3a.c src3b.c src3.h
>
> bin_PROGRAMS = foo
> foo_SOURCES = main.c ...
> foo_LDADD = $(LIBALT)
> foo_DEPENDENCIES = $(LIBALT)
>
> Now all configure has to do is to substitute @LIBALT@ with the
> relevant subset of EXTRA_LIBRARIES. I like this
> because configure does not have to know all the sources files
> involved, and Makefile.am is not cluttered with if/else blocks.
That does seem neat, but the optional modules in question are single
source files, and though there's no real problem with making libraries
with only one object file in them, this, again, seems rather
counterintuitive.
In the end, I used a mixture of these suggestions, wrote
EXTRA_libdvi2bitmap_la_SOURCES = \
GIFBitmap.cc \
PNGBitmap.cc \
kpathsea.cc
[EMAIL PROTECTED]@
libdvi2bitmap_la_LIBADD = $(EXTRALO) $(LTLIBOBJS)
libdvi2bitmap_la_DEPENDENCIES = $(EXTRALO) $(LTLIBOBJS)
in the Makefile.am, and then build up and AC_SUBST EXTRALO with
GIFBitmap.lo, PNGBitmap.lo and/or kpathsea .lo in configure.ac.
That works, and does generate the rules for the static libraries
automagically, without me having to do any sedding voodoo.
Now, is that legitimate? This is really a question, or comment, on
the Info section `What is in the API'.
I'm taking it that if you include the code to build a shared library, by
setting the appropriate _LTLIBRARIES variables, then the corresponding
_static_ library is automatically built, with all the appropriate
transformation of dependencies and variables. That seems to be the
implication of section `Building a Shared Library', but it doesn't say
it sufficiently clearly that I would be confident in moaning if automake
suddenly stopped doing this.
I'm also taking it that .lo is the documented way to express a dependency
on an object file. This same section documents that .lo is the name
of extra `libtool objects', but this sentence might be clearer as `For
each library, you should add to the library_LIBADD variable the names
of any extra libtool objects (`.lo' files) to add to the shared
library.': this makes it clearer that .lo names are something the user
can manipulate, rather than being things which magically arrive in the
_LIBADD variable by some occult means.
Finally, although the various mentions of LIBOBJS in the manual do,
together, give the impression that LIBOBJS is for replacement functions,
and set only through AC_REPLACE_FUNCS, this isn't really made explicit
anywhere -- _setting_ LIBOBJS appears _not_ to be part of the automake
API, though _using_ it in a dependency is (necessarily); that there
are instructions for hacking it if necessary, just makes things more
confusing (again, probably necessarily!). It might be valuable to make
this explicit, say in section `Program and Library Variables', or in
`Special handling...'.
I'm not moaning about the documentation. I periodicaly do this sort
of thing myself and know (oooh, lordy) how hard it is to include
everything. The `API' section is a rather important one, however. So
much of what happens in automake is magic (that's part of its point),
while at the same time being open to inspection and hacking, that it's
quite disorienting trying to work out what one is and is not allowed
to use and tinker with.
Thanks for the help with this problem.
All the best,
Norman
--
---------------------------------------------------------------------------
Norman Gray http://www.astro.gla.ac.uk/users/norman/
Physics and Astronomy, University of Glasgow, UK [EMAIL PROTECTED]
