On Fri, 20 Oct 2006 20:08:56 +0200, "Bruno Haible" said: > Charles Wilson wrote: > > When you call gnulib-tool --import/--update, it autogenerates a > > Makefile.am for the library. Sometimes it is desirable to customize > > that Makefile's behavior -- but those customizations will be lost upon > > the next --update. > > Thanks for working on this. It appears that we need first to improve the > documentation of the existing possibilities. Because you may not have > noticed that > - nearly the same customizations are available through the > --makefile-name > option; it allows you to generate a file called, say, > Makefile.gnulib, > that you include from your entirely hand-written Makefile.am,
Oh, that's interesting -- and could do *almost* everything necessary (see below). > - a lot of customizations are also possible by defining a fake module > of yours, with an empty file list, just for the purpose of putting > some > automake statements into its 'Makefile.am' section. And then use > gnulib's > --local-dir option. Also true, unless for some reason (can't think of any at the moment, but...?) order is important -- e.g. there's no way to ensure that your fake module is the first (or last) snippet. I *was* already using the --local-dir option (as you probably guessed from the patch I submitted earlier this week) -- but using it for this purpose didn't occur to me. > > Makefile.am.top > > Makefile.am.before > > Makefile.am.after > > Makefile.am.bottom > > Why are two files (Makefile.am.top, Makefile.am.bottom) not sufficient? > gnulib-tool's existing --makefile-name option acts as if one would > specify > Makefile.am.top and Makefile.am.bottom files, therefore I'd like to know > what > you can _not_ do with it? The problem comes down to assignment. Some of the variables in the section emitted by gnulib-tool prior to the snippets are assigned using '='. Therefore, you can't do this: Makefile.am: DEFAULT_INCLUDES = <some setting that's not the _default_ DEFAULT_INCLUES> AM_CPPFLAGS = -DNO_XMALLOC include Makefile.am.gnulib I suppose you *could* do it this way, tho (assuming order is not important) DEFAULT_INCLUDES = <some setting that's not the _default_ DEFAULT_INCLUES> include Makefile.am.gnulib AM_CPPFLAGS += -DNO_XMALLOC That would probably work, until gnulib-tool decides to set DEFAULT_INCLUDES as well. Then the end user has got to decide between include Makefile.am.gnulib AM_CPPFLAGS += -DNO_XMALLOC DEFAULT_INCLUDES = <override gnulib's version> and include Makefile.am.gnulib AM_CPPFLAGS += -DNO_XMALLOC DEFAULT_INCLUDES += <just add some extra stuff> But now that I think about it, the end user would still face these same issues with my scheme as well. So, I guess you're right: most of what I want to do is possible with the existing features of gnulib -- and those things that aren't possible have other workarounds. That's okay: my patch had seriously ugly code in it, anyway. You're right. If all the stuff that would happen in Makefile.before and Makefile.after are put into fake.module's Makefile.am: section, then coupled with a suitable invokation of gnulib-tool (--makefile-name Makefile.am.gnulib .... my-fake-module ...) Makefile.am ---------------- %< ------------------ Makefile.top contents include Makefile.am.gnulib (and somewhere in here my-fake-module's stuff is inserted) Makefile.bottom contents ---------------- %< ------------------ does everything necessary. -- Chuck -- Charles Wilson cygwin at removespam cwilson dot fastmail dot fm
