Re: AC_LIBOBJ and C++

[Alexandre Duret-Lutz]

Hi Norman,

>>> "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
to
  - using explicits `noinst_LIBRARIES = $(LIBALT_for_subdirN)'
    in subdirN/Makefile.am
  - 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.

[...]

-- 
Alexandre Duret-Lutz