Re: regex-0.12's regex.h seems to have a little bug

[Simon Josefsson]

Paul Eggert <address@hidden> writes:

> Julien PUYDT <address@hidden> writes:
>> Paul Eggert a écrit :
>>> Julien PUYDT <address@hidden> writes:
>>>>Stepan Kasal a écrit :
>>>>>I suggest that you get the files from gnulib CVS on savannah.
>>>>Those are GPL and not LGPL ;
>>> No, they can be released under either the GPL or the LGPL.
>>> If you use gnulib-tool to obtain that source code, it turns the
>>> copyright notice into LGPL for you automatically.
>> Hmmm... gnulib-tool wants to install it in a project -- which I don't
>> want : I just need a posix regex library. Gnulib-tool doesn't seem to
>> permit to just get the sources.
>
> I'll CC: this to bug-gnulib to see if the gnulib-tool experts can
> help out on here.

If you invoke the tool as:

gnulib-tool --create-testdir --dir=/tmp/testdir regex

It will create an entire new project in /tmp/testdir for the regex
module.  Then you can run it again:

cd /tmp/testdir
gnulib-tool --import --lgpl regex

After that, you have the sources in lib/ and the required M4 macros in
gl/.  You can copy them somewhere else, but you should call gl_EARLY
early in configure.ac, and gl_INIT later on in your configure.ac.

Due to the use of AC_LIBSOURCES, you cannot use AC_LIBOBJ or
AC_REPLACE_FUNCS in your project, unless you put the regex library in
the same directory where you put your @address@hidden  Placing gnulib
files in a directory with other files is not the typical way to use
gnulib, but your usage already appear to be non-typical.  I agree with
Bruno that the consequences of AC_LIBSOURCES is serious flaw in gnulib
currently.  Hopefully it can be fixed with newer m4/automake/libtool
(I forget which newer versions were needed, they depended on each
other somehow).  I'm not sure what the supposed advantage with
AC_LIBSOURCES was compared to the old scheme.

Using gnulib modules without autoconf is not supported, as far as I
know.

Hope this helps,
Simon