[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Calling other external Makefiles and outside Make systems

From: Alexandre Duret-Lutz
Subject: Re: Calling other external Makefiles and outside Make systems
Date: Sun, 25 Jan 2004 10:55:46 +0100
User-agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux)

>>> "John" == John Ling <address@hidden> writes:

 John> My project, for which I use Automake, needs to build libraries from
 John> projects outside of itself.  I tried incorporating this outside
 John> project's Makefiles into my own but without success.  This is because
 John> they define things like CPPFLAGS and top_srcdir in their own
 John> Makefiles.  If I try to include these into my own it will
 John> obviously conflict with what my own project needs.  If anyone knows a
 John> way around this let me know.

 John> In the meantime, I think the solution is to simply call the Makefile
 John> of this other project and let it do the building of these libraries.
 John> But, I want to do this call from inside my

Hi John,

Here is proposed section about this for the manual.  Please let
me know if this answers your question, or if it can be improved
in any way (including English mistakes).

When Automake Isn't Enough

In some situations, where Automake is not up to one task, one has to
resort to handwritten rules or even handwritten `Makefile's.
* Menu:
* Extending::                   Adding new rules or overriding existing ones.
* Third-Party Makefiles::       Integrating Non-Automake `Makefile's.

[I'm skipping the `Extending' node here.  It contains all what
was under the title `When Automake Isn't Enough' in previous manual.]

Third-Party `Makefile's

In most projects all `Makefile's are generated by Automake.  In some
cases, however, projects need to embed subdirectories with handwritten
`Makefile's.  For instance one subdirectory could be a third-party
project with its own build system, not using Automake.
   It is possible to list arbitrary directories in `SUBDIRS' or
`DIST_SUBDIRS' provided each of these directories has a `Makefile' that
recognizes all the following recursive targets.

   When a user runs one of these targets, that target is run recursively
in all subdirectories.  This is why it is important that even
third-party `Makefile's support them.

     Compile the entire package.  This is the default target in
     Automake-generated `Makefile's, but it does not need to be the
     default in third-party `Makefile's.

     Copy files to distribute into `$(distdir)', before a tarball is
     constructed.  Of course this target is not required if the
     `no-dist' option (*note Options::) is used.

     Install or uninstall files (*note Install::).

     Install only the Texinfo documentation (*note Texinfo::).

     Create install directories, but do not install any file.

     Check the package (*note Tests::).

     Cleaning rules (*note Clean::).

     Build the documentation in various format (*note Texinfo::).

     Build `TAGS' and `CTAGS' (*note Tags::).

   If you have ever used Gettext in a project, this is how it works.
The `Makefile's 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.
   Directories which are only listed in `DIST_SUBDIRS' but not in
`SUBDIRS', need only the `distclean', `maintainer-clean', and `distdir'
rules (*note Top level::).
   Usually, many of these rules are irrelevant to the third-party
subproject, but they are required for the whole package to work.  It's
OK to have a rule that does nothing, so if you are integrating a
third-party project with no documentation or tag support, you could
simply augment its `Makefile' as follows:

     EMPTY_AUTOMAKE_TARGETS = dvi pdf ps info html tags ctags
   It is sometimes inconvenient to modify a third-party `Makefile' to
introduce these required targets.  For instance one may want to keep
the third-party sources untouched to ease upgrade to new versions.

   Here are two other ideas.  If GNU make is assumed, one possibility is
to add to that subdirectory a `GNUmakefile' that defines the required
targets and include the third-party `Makefile'.  For example if we
assume `Makefile' defines all targets except the documentation targets,
and that the `check' target is actually called `test', here the
`GNUmakefile' we could write:

     # First, include the real Makefile
     include Makefile
     # Then, define the other targets needed by Automake Makefiles.
     .PHONY: dvi pdf ps info html check
     dvi pdf ps info html:
     check: test

   A similar idea, that does not use `include' is to write a proxy
`Makefile' that dispatches rules to the real `Makefile', either with
`$(MAKE) -f Makefile.real $(AM_MAKEFLAGS) target' (if it's OK to rename
the original `Makefile') or with `cd subdir && $(MAKE) $(AM_MAKEFLAGS)
target' (if it's OK to store the subdirectory project one directory
deeper).  The good news is that this proxy `Makefile' can be generated
with Automake.  All we need are -local targets (*note Extending::) that
perform the dispatch.  Of course the other Automake features are
available, so you could decide to let Automake perform distribution or
installation.  Here is a possible `':

             cd subdir && $(MAKE) $(AM_MAKEFLAGS) all
             cd subdir && $(MAKE) $(AM_MAKEFLAGS) test
             cd subdir && $(MAKE) $(AM_MAKEFLAGS) clean
     # Assuming the package knows how to install itself
             cd subdir && $(MAKE) $(AM_MAKEFLAGS) install-data
             cd subdir && $(MAKE) $(AM_MAKEFLAGS) install-exec
             cd subdir && $(MAKE) $(AM_MAKEFLAGS) uninstall
     # Distribute files from here.
     EXTRA_DIST = subdir/Makefile subdir/program.c ...

   Pushing this idea to the extreme, it is also possible to ignore the
subproject build system and build everything from this proxy `Makefile'.

Alexandre Duret-Lutz

reply via email to

[Prev in Thread] Current Thread [Next in Thread]