[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-gnulib] [patch] feature enhancement for gnulib-tool
From: |
Charles Wilson |
Subject: |
Re: [bug-gnulib] [patch] feature enhancement for gnulib-tool |
Date: |
Fri, 20 Oct 2006 14:42:04 -0400 |
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