[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AC_LIBOBJ and C++
Re: AC_LIBOBJ and C++
Wed, 23 Jul 2003 00:11:30 +0200
Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)
>>> "Norman" == Norman Gray <address@hidden> writes:
Norman> How does one optionally include C++ (or any non-C)
Norman> sources in automake?
Norman> I don't mean functions to replace missing system functionality, but
Norman> modules within a package which the user may want or have to omit at
Norman> ./configure time.
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.
Norman> I did have this working by defining and AC_SUBSTing a variety of
Norman> @otherOBJ@ variables and adding them to the libFOO_la_LIBADD line.
Norman> That sort-of works, but it would require me to do fancy sedding to
Norman> turn the list of .o files which I've accumulated from configure.ac
Norman> into the .lo files which should be put on the _LIBADD line.
Yes. This is one way to compile sources conditionally.
The `Conditional Sources' node of the manual shows another possibility
based on Automake conditionals.
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.
EXTRA_LIBRARIES causes build rules to be output for each
libraries, even though they are not built by default.
foo_DEPENDENCIES triggers the build of the required libraries.
Note this works well because the build rules for the libraries
are in the same Makefile as the rules for the program that
depends on them. If you use many subdirectories you can't
rely on _DEPENDENCIES to trigger the build and can resort
- using explicits `noinst_LIBRARIES = $(LIBALT_for_subdirN)'
- merge the subdirectory Makefile.ams into the top Makefile.am
so that everything is built from the same place (can
be helped with `include')
You can see an example of such a setup (`foo_DEPENDENCIES = $(LIBALT)',
+ `include' to gather rules from subdirectories) in Heroes (heroes.sf.net),
where it is used to choose between different media libraries.
See src/media/README and grep for LIBALT.
I'd expect this to work with LTLIBRARIES too (EXTRA_LTLIBRARIES
should be comparable to noinst_LTLIBRARIES when it comes to
linking), but I never had the occasion to try.
Norman> [ Just by the way, there appear to be a couple of "@&t@" strings
Norman> astray in that section. Is this fallout from some not-quite-working
Norman> escaping, or is it something more arcane than I recognise!? ]
This is a trick to prevent Autoconf from complaining about the
direct assignment to LIBOBJS.