John> Thank you Alexandre for providing that documentation. I found the
John> last section on "proxy" makefiles helpful in incorporating the other
John> projects makefile. I did get it working with this method. For
John> example, I did:
John> lib_LIBRARIES += libloader.a
John> libloader.a :
John> cd cpp/db/loader; \
John> $(MAKE) -f ./Makefile.loader; \
John> mv libloader.a $(srcdir)/lib
$(srcdir) can be an absolute path, or a path relative to the
current directory (depending on how `configure' was run). In
the latter case you cannot use it after a `cd'. Also
I do not understand the purpose of `/lib'. The rule is about
creating libloader.a in the current directory, not in lib/.
Maybe you want
lib_LIBRARIES += libloader.a
libloader.a:
cd cpp/db/loader && $(MAKE) -f ./Makefile.loader
mv cpp/db/loader/libloader.a .
or
lib_LIBRARIES += lib/libloader.a
lib/libloader.a:
cd cpp/db/loader && $(MAKE) -f ./Makefile.loader
mv cpp/db/loader/libloader.a lib
(likewise for other targets)
[...]
John> With respect to my first idea, I've gotten some feedback from the
John> makers of this other build system. So I give here a more detailed
John> background of my situation.
John> The idea is that the user will be responsible for installing and
John> building this other package. So this other package and its built
John> libraries will reside outside of my source tree, completely
John> independent. In order to build an application that uses this library,
John> requires that I include a Makefile.mk (specifies many variables like
John> top_srcdir, builddir, CXXFLAGS, CFLAGS, etc...) and a Makefile.lib
John> (specifies many targets).
John> What I was hoping to do was to include these two Makefile.lib and
John> Makefile.mk into my project's Makefile.am. My fear was that the
John> CXXFLAGS and top_srcdir etc in my project will get overriden with what
John> is set here by Makefile.lib and Makefile.mk.
They will. Also in Automake Makefiles, CFLAGS, CPPFLAGS, CXXFLAGS and
siblings are *user* variables (user are allowed to type things like
`./configure CFLAGS=-ggdb' to customize the build) and it's considered
bad taste to override these in Makefile.am (or any included fragment).
We use AM_CFLAGS, AM_CPPFLAGS, AM_CXXFLAGS... instead.
[...]
John> So, given this information, can I include the Makefile.lib and
John> Makefile.mk at a point just prior to the step where automake generates
John> the variables for CPPFLAGS, etc ... so that I can guarantee that the
John> CPPFLAGS etc will first be defined by the other build system's
John> templates and the be overridden by what automake generates. If I can
John> guarantee this, I can then do:
John> CPPFLAGS += $(ORIG_CPPFLAGS)
John> Do you know if this is feasible? If so, at where do I do the include
John> of these two template Makefiles? At the beginning of Makefile.am?
This these fragment set the initial value of CPPFLAGS, you must
include then anywhere before the above `+='.
John> Finally, in regards to your document, I think the transition from
John> listing the Makefile recursive targets to the paragraph talking about
John> Gettext was a little confusing. I'm still not sure if you are using
John> Gettext as just an arbitrary example or if I am supposed to be using
John> Gettext specifically to somehow handle this issue.
It's just an example. I've changed that paragraph to
If you have ever used Gettext in a project, this is a good example of
how third-party `Makefile's can be used with Automake. The `Makefile's
`gettextize' puts in the `po/' and `intl/' directories are handwritten
`Makefile's that implement all these targets. That way they can be
added to `SUBDIRS' in Automake packages.