Autotools build fails due to subdir-objects option in AM_INIT_AUTOMAKE

autoconf, automake, autotools, libtool

Solution

From the `automake-1.14.1` `NEWS` file:

The next major Automake version (2.0) will unconditionally activate
the 'subdir-objects' option.  In order to smooth out the transition,
we now give a warning (in the category 'unsupported') whenever a
source file is present in a subdirectory but the 'subdir-object' is
not enabled.  For example, the following usage will trigger such a
warning:

        bin_PROGRAMS = sub/foo
        sub_foo_SOURCES = sub/main.c sub/bar.c

So in preparation for this, you need `subdir-objects` as one of the options in `AM_INIT_AUTOMAKE`, if you use subdirectories in 'object' names as described above. This option will be 'on' by default in 2.0.

If you could provide the `Makefile.am` for the directory that fails, it might provide a clue as to why the relative directories aren't matching up.

Ok, there a couple of things about this `Makefile.am`. Firstly, there are ways to correctly version a libtool library, and `@MY_API_VERSION@` substitutions aren't the way to go. You could form a numeric string for example, in `configure.ac`, followed by `AC_SUBST(MY_API_VERSION)`.

In `Makefile.am` : `libadapter_la_LDFLAGS = -release $(MY_API_VERSION)` will put this information in the `libadapter.la` libtool meta-file.

For serious version control, where interface compatibility, revisions, binary compatibility, etc., are desirable, you can have a look at the libtool reference on versioning. Important system libraries, particularly GNOME/GTK (look at their `configure.ac` files!), go all-out on this stuff. I certainly don't, unless I'm considering releasing something into the wild. I still find it confusing.

Omitting `@MY_API_VERSION@`, you can also stick with `libadapter_la_SOURCES`. However, the source files aren't found relative to any `builddir` path, which was perhaps the source of your `.Plo` file issue. The `builddir` variables describe where the built components are found - you can also build out-of-tree, and this is a good test to see if your automake setup is robust. Some packages promote this, e.g., go to the top of the package, make a directory there called `build` or `my_build` or whatever suits:

`cd my_build; ../configure <options>; make`

The package, it's source tree and recursive directories will be left alone, everything will be built under the `my_build` directory, and the subdirectories will mirror those of your source tree, only they will be full of built objects, libraries, executables, etc. `make install` should also work perfectly using the generated `my_build/Makefile`.

But returning to the point - those source files are relative to the `$(srcdir)` directory, which corresponds to the current (recursive) `Makefile.am`'s directory. The various `builddir` and `srcdir` variables are described here.

If your `src` directory is located under the top-level directory, you could use: `"$(top_srcdir)/src/sourceA.cpp"` - notice that `"$(srcdir)/src/sourceA.cpp"` would be wrong, as it would be like specifying `"$(top_srcdir)/src/src/sourceA.cpp"` in this case.

You could use `"$(srcdir)/sourceA.cpp"`, but this directory is implicit anyway. All you need is:

`libadapter_la_SOURCES = sourceA.cpp sourceB.cpp`

It is also perfectly acceptable to put any header files in the `src` directory used by `libadapter` in the `SOURCES` list. A change of a header will rebuild what's required.

Anyway, I didn't mean to write this much, but I know how frustrating it is get clear information about the autotools. The Autotools Mythbuster provides excellent 'walk-through' tutorials, and stays very up to date.

Problem

Original source