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

[Simon Josefsson]

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

>> Renaming LTLIBOBJ variable temporarily worked, but I haven't not
>> tested all combinations (e.g., with/without libtool).
>> 
>> I don't think we can get rid of gl_EARLY, though, unless it is
>> possible to hook into AC_PROG_CC automatically somehow.
>
> AC_PROVIDE_IFELSE([AC_PROG_CC], [gl_EARLY],
>     [m4_define([AC_PROG_CC], defn([AC_PROG_CC])[gl_EARLY])])
>
> That is: If AC_PROG_CC has been expanded at this point, expand gl_EARLY right
> now, otherwise hook it onto the end of AC_PROG_CC so that it will be expanded
> right after the next call to AC_PROG_CC.

Where would this snippet go?  gnulib.m4?  Would it have the proper
effect, then?  I.e., run before the C compiler has been used for real
tests?  Is it good style to do this?  Could it break something?

>> I wish there were some non-positional way to specify function
>> parameters in M4, though.  E.g., lisp inspired:
>> 
>> gl_INIT(:module [getopt progname strdup dummy ...], :sourcebase [gl], 
>> :license [LGPL])
>
> Something like this is slated for after the 2.0 release (which will happen as
> soon as the dust settles on the libtool-2.0 release).
>
> gl_INIT([module=getopt progname strdup ...], [sourcebase=gl], [license=LGPL])

Nice!

> I might be able to tweak the syntax table implementation to allow a lispier
> notation too...

I'm not sure, but it is probably better to only support one scheme.
Easier to match using sed expressions.  More room for future
expansion.  Etc.

Thanks.