Re: Calling other external Makefiles and outside Make systems

[Alexandre Duret-Lutz]

>>> "John" == John Ling <address@hidden> 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