Well, when I run $(MAKE) -f ./Makefile.loader it does create the libloader.a in the cpp/db/loader directory. But, I want to collect all my libraries into one directory just underneath $(top_srcdir)/lib. Sorry I wrote $(srcdir) in my example but I meant $(top_srcdir).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)
[...]
Ok thats what I thought.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 `+='.
I look forward to reading the final version. It will be a very useful document.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.
John
