Re: [bug-gnulib] [patch] feature enhancement for gnulib-tool

[Charles Wilson]

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