[Bug-gnulib] Re: Docs for gnulib-tool --import

[Simon Josefsson]

"Gary V. Vaughan" <address@hidden> writes:

> Hi Simon,
>
> Simon Josefsson wrote:
>> "Gary V. Vaughan" <address@hidden> writes:
>>>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.
>
> If you want to retain the possibility of adding additional arguments, then
> it is easy to take advantage of the fact that the macro is simply writing
> some shell code into configure for us.  So we could invoke gl_INIT thus:
>
> gl_INIT([strdup dummy ...],
>             [source_base=lgl; m4_base=lgl/m4; lib=liblgl; license=LGPL],
>         [error getopt progname ...],
>             [source_base=gl; m4_base=gl/m4; lib=libgl])
>
> And in the implementation emit first the default value setting, and then
> the shell code block which will override only those settings listed.  As
> long as the variable values are either saved or no longer used before
> calling m4_shiftn and recursing there will be no problem in the generated
> configure code, and adding new options is a snap.
>
> This method also lends itself well to the rewriting for parsing hint I
> gave earlier in the thread.

I like this approach better.  Perhaps the variables should be slightly
more official looking though; a'la gl_source_base, gl_m4_base,
gl_library_name etc.

Thanks.