Re: Calling other external Makefiles and outside Make systems

[Ralf Wildenhues]

* Alexandre Duret-Lutz wrote on Sun, Jan 25, 2004 at 10:55:46AM CET:
> 
> 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).

I'm not John, but I'll answer anyway.  I like the section, especially
the idea of possibly not having to modify the subproject at all.

A few issues that come to my mind possibly worth improving (not the
documentation, but Auto{make,conf} with this respect) are
- provide a way to communicate the value of AC_CONFIG_AUX_DIR
  to sub-package configure scripts (do we need to think about
  AC_CONFIG_MACRO_DIR, too?), so they don't need adaptation.
- With this respect, what is the value of top_builddir, top_srcdir
  and are these properly documented?  I only found out about
  distdir and top_distdir in the manual.

Other than that, a few language hints (disclaimer: from a non-native):

> `installdirs'
>      Create install directories, but do not install any file.

files?

> `dvi'
> `pdf'
> `ps'
> `info'
> `html'
>      Build the documentation in various format (*note Texinfo::).

formats

>    If you have ever used Gettext in a project, this is how it works.

I would use a colon (`:') at the end of this sentence.

> 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'
           ^
AFAIK no comma here (the subclause is a restrictive modifier).

> 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
>      .PHONY: $(EMPTY_AUTOMAKE_TARGETS)
>      $(EMPTY_AUTOMAKE_TARGETS):
>    
>    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

`:' after ideas, as above.

> 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:

... target is actually called `test', we could write a `GNUmakefile'
like this:

>      # 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
                   ^
AFAIK no comma here (or put one there and one after `include', since
here the modification is rather unrestrictive).

> `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).
[...]

Regards,
Ralf