Bruno Haible <[EMAIL PROTECTED]> 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
