Automake Subdir-Objects Is Disabled

subdir-objects option for automake doesn't work

That's not what the subdir-objects option does. It puts intermediate build results, especially *.o object files, in the same directory as the sources from which they are built. In particular, you should find main.o there instead of in the top directory.

The final build result, on the other hand, must be what and where you specify in your Automake file. If you want toto to go in the src/ directory too, then use this Makefile.am:

MAINTAINERCLEANFILES = Makefile.in aclocal.m4 config.h.in configure depcomp install-sh missing compile
bin_PROGRAMS=src/toto
src_toto_SOURCES=src/main.c

Conditional subdir-objects

According to the list of automake options, no. What you can do instead is remove subdir-objects from the call to AM_INIT_AUTOMAKE and add it to the Makefile.am files where you actually want it. You do that by putting the line AUTOMAKE_OPTIONS = subdir-objects at the top of any relevant Makefile.am. (There's no no-subdir-objects option, apparently.)

fail to build libprocess, something wrong with the autotools

so I've added the 'subdir-objects' in the configure.ac file

This is likely your problem. Your bootstrap problem is just a warning.

Recent versions of of automake will give this error for non-recursive Makefile.am, like this question.

Best way to compile subdirectories into libraries with automake?

There are numerous oddities in what you've presented, and one clear error. You say,

I get a file called libprocs.la in procs but I don't get a binary. I
am also fairly certain that my Makefiles are wrong since I can't even
compile main.cpp by hand.

Surely make's output contains one or more error messages that explain why the build fails. Unless your makeing only the procs subdirectory in the first place, I guess, in which case of course you would not be getting main built.

But I'm reasonably confident that I can guess: you're getting a linker error complaining that it can't find ProcA_SubprocA::ProcA_SubprocA. This would be because although your Makefile specifies that the library should be built (and also installed), it nowhere says that it needs to be linked into main. There's a pretty easy fix for that, which I will return to in a moment.

First, however, let's talk about libprocs.la. The .la suffix is meaningful to the Autotools, designating a "libtool archive", but you're actually building it as an ordinary static library. Indeed libtool isn't doing anything particularly useful for you here; I would dump it by removing the LT_INIT from your configure.ac (and do not run libtoolize again, as it will put that back). Then, change the name of the library to be built to the more standard libprocs.a.

Furthermore, since this library seems to be intended only for use with the one program being built, it is unhelpful to include it in the install in its own right. Therefore, instead of designating it in lib_LIBRARIES, designate it as a non-installed convenience library:

noinst_LIBRARIES = libprocs.a

You will then need to make a corresponding change to the library's SOURCES variable:

libprocs_la_SOURCES = ...

libprocs_a_SOURCES = ...

Coming back to the main program now, you need to tell make (and Automake) that the library needs to be linked into program main. There are a few variations on how you could do that, but I'm going to suggest a fairly simple one:

main_LDADD = procs/libprocs.a

After those changes, rerun autoreconf (but not libtoolize). Remember, however, that you need to run that only after changing Autotools sources -- just Makefile.am and configure.ac files in your case. It is a detail of maintaining and developing the package and its build system in particular. It should not be a routine part of building or installing the package.

Autotools complain about files compiled with different contexts

To get rid of the option, simply enable subidr-objects by adding the subdir-objects option to your Makefile.am. e.g.:

  AUTOMAKE_OPTIONS = subdir-objects foreign

This will create a filesystem hierarchy of binary objects.

e.g. of your Makefile.am contains:

foo_SOURCES=foo.c bar/bar.c

then the objects generated during the build will be like

foo.o bar/bar.o

When not using subdir-objects, you would instead have

foo.o bar.o

multiple contexts

if you want to build the same source files multiple times, you want to find a way to ensure that the binary objects get unique names.
automake does this automatically, if it thinks that the objects are compiled with different flags.
You can therefore trick it into creating unique suffixes, by providing (dummy) FLAGS for all contexts:

AUTOMAKE_OPTIONS = subdir-objects

bin_PROGRAMS=foo
foo_SOURCES=main.c foo.c bar/foo.c
# we need to override the *_CPPFLAGS (using the defaults) to get unique names
foo_CPPFLAGS=$(AM_CPPFLAGS)

lib_LTLIBRARIES=libfoobar.la
libfoobar_la_SOURCES=lib.c foo.c bar/foo.c
# alternatively we can override *_CFLAGS
libfoobar_la_CFLAGS=$(AM_CFLAGS)

This will build foo.c (in the root) for both "foo" and "libfoobar", without generating a conflict:

$ ls -1 *.o */*.o
bar/foo-foo.o
bar/libfoobar_la-foo.o
foo-foo.o
foo-main.o
libfoobar_la-foo.o
libfoobar_la-lib.o

---

Related Topics