Re: Calling other external Makefiles and outside Make systems

[Ralf Wildenhues]

* Alexandre Duret-Lutz wrote on Mon, Jan 26, 2004 at 09:56:41PM CET:
> >>> "Ralf" == Ralf Wildenhues <address@hidden> writes:
> 
>  Ralf> A few issues that come to my mind possibly worth
>  Ralf> improving (not the documentation, but Auto{make,conf}
>  Ralf> with this respect) are
> 
>  Ralf> - provide a way to communicate the value of AC_CONFIG_AUX_DIR
>  Ralf> to sub-package configure scripts (do we need to think about
>  Ralf> AC_CONFIG_MACRO_DIR, too?), so they don't need adaptation.
> 
> I don't understand this.  If a third-party package uses an
> auxiliary script, say install-sh, then that third-party package
> already contains install-sh and does not care about the parent's
> auxdir.  Am I missing something?  What kind of adaptation do you
> want to avoid passing AC_CONFIG_AUX_DIR?

Oh, yes, you're right.  braino, sorry.  This one is not about
not changing the subpackage, but about saving space in the combined
package.  After all, auxiliary scripts with the same name are supposed
to be identical, right?

>  Ralf> - With this respect, what is the value of top_builddir,
>  Ralf> top_srcdir and are these properly documented?  I only
>  Ralf> found out about distdir and top_distdir in the manual.
> 
> It's because they really are predefined Autoconf substitutions.

Ok.  So they refer to the top of the subpackage trees.

> Anyway, thank you for mentioning that.  I really forgot to
> though about VPATH builds while writing this.
> 
> Someday I would like to write two introductory sections to the
> manual.  One section would be `Automake projects from the user's
> perspective', explaining the various targets available and
> different uses of the GNU build system (cross-compilation, VPATH
> builds, DESTDIR installs).  I don't really expect end-users to
> read the Automake manual, but it is a nice way to introduce
> these concept before showing how they work.  The other section
> would be the `developer's perspective'.  It would explain how a
> project is usually organized, the purpose of each autotool, and
> how everything fits to achieve the feature listed in the
> previous section.  Perhaps this second section will need to be
> split in many sub-sections, explaining how DESTDIR installs,
> cross-compilation, VPATH builds, etc. work.  The discussion
> about srcdir/top_srcdir/top_buildir belongs there, IMHO.

ACK.  This would IMHO be a worthwhile goal, but a lot of work, too.

The top_{src,build}dir thing above is one of those issues deeply hidden
from users.  For example, until your explanation I had no idea what
part of the autotools created it, and -- now the mere autotools user
speaking -- frankly, I didn't want to know.

>  Ralf> Other than that, a few language hints (disclaimer: from a
>  Ralf> non-native):
> 
> Thanks again.  The only changes I didn't include are the colons,
> but that's a matter of taste and if someone insists I can put
> them in.

That choice is fine.

> Here is a new version of that section, with additions
> highlighted on the left.

Looks good to me, so only typos:

[ snip lots ]
>   
>      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 this to work in
> | VPATH builds, `GNUmakefile' must lie in the build directory; the
> | easiest way to do this is to write a `GNUmakefile.in' instead, and have
> | it processed with `AC_CONFIG_FILES' from the outer package.  For
> | example if we assume `Makefile' defines all targets except the
           ^
comma here

> | documentation targets, and that the `check' target is actually called
> | `test', we could write `GNUmakefile' (or `GNUmakefile.in') like this:

[ snip ]

>      Pushing this idea to the extreme, it is also possible to ignore the
>   subproject build system and build everything from this proxy
> | `Makefile.am'.  This might sounds very sensible if you need VPATH
                                    ^
sound

> | builds but the subproject does not support them.

Regards,
Ralf