Re: gnulib-tool: new option --makefile-name

[Simon Josefsson]

Bruno Haible <address@hidden> writes:

> While doing the coreutils changes, Paul found the answer to the long-standing
> question how gnulib-tool could be used without requiring a lib/ directory of
> its own and while still maintaining a clear separation between hand-maintained
> files and autogenerated files. Namely, rename the gnulib Makefile.am to some
> other name and include it from the real Makefile.am.
>
> This patch adds an option --makefile-name that does this.

I mentioned that approach earlier in:

http://article.gmane.org/gmane.comp.lib.gnulib.bugs/1969
http://article.gmane.org/gmane.comp.lib.gnulib.bugs/2021

The problem in automake that would had to be fixed was this:

http://thread.gmane.org/gmane.comp.sysutils.automake.bugs/1659

Briefly, the gnulib Makefile.am snippet uses += to add contents to
variables, such as EXTRA_DIST, which are also useful to use in the
Makefile.am that includes the gnulib Makefile.am snippet.  But
automake doesn't permit += without an earlier 'EXTRA_DIST = ...'
definition.

One solution to this, that I see now, is to have a "early" makefile.am
snippet too.  I.e., add a gnulib-early.mk that contains:

AUTOMAKE_OPTIONS = 1.5 gnits no-dependencies
noinst_HEADERS =
EXTRA_DIST =
BUILT_SOURCES =
SUFFIXES =
MOSTLYCLEANFILES = core *.stackdump
MOSTLYCLEANDIRS =
CLEANFILES =
DISTCLEANFILES =
MAINTAINERCLEANFILES =
AM_CPPFLAGS =

And then require that users write Makefile.am that follows this
structure:

include gnulib-early.mk
...there own stuff...
include gnulib.mk
...possibly more stuff...

This seems somewhat inflexible, though.  I'd rather change automake to
permit += for variables that haven't been defined yet, but that didn't
seem to happen.  I'm not sure there are other solutions.

Am I missing something?

/Simon