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.
