>>> "John" == John Ling <[EMAIL PROTECTED]> writes:
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. -- Alexandre Duret-Lutz