> > What about adding a test to find out the extension of (static)
> > libraries? Having a LIBEXT variable would be quite helpful.
>
> [...] you can alternatively use the gnulib module havelib (which
> will use the logic in the config.rpath file to set libext).
This looks very promising, thanks!
On Monday 05 January 2009 05:24:17 Paolo Bonzini wrote:
> >> is there a standard way for addressing this ? or should i cheat and set
> >> the vars to yes before calling gl_{EARLY,INIT} ? if i add a line like
> >> this: gl_cv_func_printf_infinite_long_double=yes
> >
> > Yes, that (seeding the cach
Jim Meyering writes:
> So I conclude that the choices are
>
> Perl
> Python
> Ruby
>
> If using Perl, we could easily restrict ourselves to
> features of 5.8 or even older. With Python and especially Ruby,
> I'd advocate requiring much more recent versions, due to their relative
> immaturi
> So I conclude that the choices are
>
> Perl
> Python
> Ruby
>
> If using Perl, we could easily restrict ourselves to
> features of 5.8 or even older. With Python and especially Ruby,
> I'd advocate requiring much more recent versions, due to their relative
> immaturity.
Agreed.
Consid
>> is there a standard way for addressing this ? or should i cheat and set the
>> vars to yes before calling gl_{EARLY,INIT} ? if i add a line like this:
>> gl_cv_func_printf_infinite_long_double=yes
>
> Yes, that (seeding the cache) is the recommended approach.
That, or --avoid if the modules
"Bruno Haible" wrote:
> If gnulib-tool was to be rewritten in another programming language than
> shell + sed, what would be the good choices?
>
> The foremost criteria IMO should be the maintainability, i.e. the ability for
> us and for new contributors to gnulib to master this programming langua
