[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug-gnulib] Re: Docs for gnulib-tool --import
From: |
Simon Josefsson |
Subject: |
[Bug-gnulib] Re: Docs for gnulib-tool --import |
Date: |
Tue, 12 Oct 2004 13:39:01 +0200 |
User-agent: |
Gnus/5.110003 (No Gnus v0.3) Emacs/21.3.50 (gnu/linux) |
"Gary V. Vaughan" <address@hidden> writes:
> Hi Simon,
>
> Simon Josefsson wrote:
>> "Gary V. Vaughan" <address@hidden> writes:
>>
>>
>>>>gl_INIT([getopt progname strdup dummy ...], [gl], [gl/m4], [libgl], [LGPL])
>>>>
>>>>Or possibly something like:
>>>>
>>>>gl_INIT([[strdup dummy ...], [lgl], [lgl/m4], [liblgl], [LGPL]],
>>>> [[error getopt progname ...], [gl], [gl/m4], [libgl]])
>>>
>>>Yes please! That would be cool :-)
>>
>>
>> Before implementing this, could someone more familiar with M4 say if
>> the latter is a good idea or not? [[snip]]
>
> I didn't notice the nested quoting when I first looked at it. Nesting M4
> quotes this way is unidiomatic, and it makes it difficult to write macros that
> unwrap the quote layers at the right point.
Thanks, that is what I was unsure about.
> The style used by M4's own macros, and m4sugar.m4 in Autoconf is to shift()
> away the first batch of arguments and call ourselves again recursively. The
> invocation would then be (swapping arg order for readability, and using []
> to accept the defaults):
>
> gl_INIT([lgl], [lgl/m4], [liblgl], [LGPL],
> [strdup dummy ...],
> [gl], [gl/m4], [libgl], [],
> [error getopt progname ...])
The problem is that this is inflexible. I suspect we may need more
parameters later on; the directory names, license, library name and
modules are what is needed now. Another useful parameter could
(theoretically) be whether libtool should be used, per directory.
> Not necessarily: gnulib-tool can always call M4 outside of autoconf with
> gl_INIT defined to rewrite its arguments in an easy to parse way using m4sh.m4
> (i.e autom4te -l m4sh gnulib-rewrite.m4 configure.ac):
Thanks for the hint.
>> On the other hand, there is an advantage of having only one entry
>> point, otherwise gnulib-tool have to remember state between each call
>> to gl_INIT. This is probably needed to, for example, generate
>> gl_EARLY properly, as a superset of all gl_EARLY contents generated by
>> each gl_INIT.
>
> Agreed.
So I might end up with the multiple gl_INIT approach.
I'll look into this during the next few days.
Thanks,
Simon
- Re: [Bug-gnulib] Docs for gnulib-tool --import, Gary V. Vaughan, 2004/10/06
- [Bug-gnulib] Re: Docs for gnulib-tool --import, Simon Josefsson, 2004/10/06
- [Bug-gnulib] Re: Docs for gnulib-tool --import, Gary V. Vaughan, 2004/10/06
- [Bug-gnulib] Re: Docs for gnulib-tool --import, Simon Josefsson, 2004/10/11
- Re: [Bug-gnulib] Re: Docs for gnulib-tool --import, Gary V. Vaughan, 2004/10/12
- [Bug-gnulib] Re: Docs for gnulib-tool --import,
Simon Josefsson <=
- [Bug-gnulib] Re: Docs for gnulib-tool --import, Gary V. Vaughan, 2004/10/12
- [Bug-gnulib] Re: Docs for gnulib-tool --import, Simon Josefsson, 2004/10/12
- [Bug-gnulib] Re: Docs for gnulib-tool --import, Gary V. Vaughan, 2004/10/12