Re: installable gnulib library

[Gary V. Vaughan]

[adding bug-autoconf for AC_COMPILE_IFELSE comment]

On 10 Oct 2010, at 21:35, Bruno Haible wrote:
> Hi Gary,

Hallo Bruno,

Thanks for the quick feedback.

>> I think your script is *much* more complicated than it needs to be. Far
>> easier to let the existing gnulib machinery populate an installable
>> libposix project, surely? See below for my alternative two line script =)O|
> 
> I agree that while a single-file bash script was a good way for Bruce to
> communicate his progress with the rest of us, long-term it is better to do
> that with a set of files in the git repository.
> 
> Since creating a separate git repository is a lot of administrative work,
> I would suggest that you (Bruce + Gary) create a subdirectory in gnulib,
> called 'libposix', with files such as
>  configure.ac
>  Makefile.am
>  version.in.h
>  version.c
>  README
>  libposix.m4
>  autogen.sh (or bootstrap if you prefer that)
> and then use "gnulib-tool --import" instead of "gnulib-tool --create-testdir".

Agreed.

>> It occurs to me also, that when another gnulib using project (that relies on
>> non-libposix modules) wants to minimise it's configury by requiring libposix,
>> gnulib-tool will need an --avoid-posix option or similar so as not to end up
>> pulling another copy of the posix modules and their dependencies into the
>> new project.
> 
> Hmm. That's a good point. But often the projects (especially coreutils)
> need the newest stuff from gnulib, and a libposix.so that is 6 months old
> will cover maybe 80% but not 100% of what coreutils wants.

In that case, coreutils could drive impetus for a new release of libposix...
an old libposix that is not good enough for coreutils is going to be deficient
for other clients too.

> But for other packages, which add libposix to their required dependencies,
> such an option would be useful. Should I implement it? Other thoughts about 
> it?

If you can add it easily, that would be great.  I won't be able to make use
of it until libposix is easily available though, so if it's anything other
than trivial, it can wait until we've nailed down the libposix implementation.

> What about the unit tests of gnulib modules, when a package is using an 
> installed
> libposix?

If the package specifies --with-test, only the tests for the non-libposix 
modules are needed... the build of libposix itself should have taken care
of passing the posix module tests before it was installed (I'm seeing a
failure there at the moment actually, but I'll post in a new thread).

>> Also, while I understood why it was done at the time, the future of a
>> comprehensive libposix looks bleak when fnmatch-posix, memset, strcspn and
>> other arguably dangerous, but none-the-less posix specified api functions
>> are marked as obsolete.  I'd have a lot more confidence in a gnulib based
>> libposix if those functions were marked instead as deprecated with a pointer
>> to the better alternative.  Obsolete suggests that support is going away.    
>>  
> 
> I think you are confusing the terms "deprecated" and "obsolete". In my
> understanding, "deprecated" means "support is going away, please use the
> suggested replacement". Whereas "obsolete" merely means "you don't need it".

I understand them the other way around, yes.  But, that's fine, as long
as those libposix modules are not in imminent danger of removal from gnulib,
I'm more than happy.

>> ## Makefile.am:
>> 
>> ACLOCAL_AMFLAGS = -I m4
>> SUBDIRS = libposix tests
> 
> Ahem, there are two things missing here:
> 
>  - You want to install the library, which can be done by specifying to
>    gnulib-tool a module (via --local-dir) which contains
>      lib_LTLIBRARIES = libposix.la
>    When gnulib-tool sees this declaration in a module, it will not emit
>      noinst_LTLIBRARIES = libposix.la

Okay, thanks.

>  - You want to install the header files, while transforming their
>    inclusion guard, for example, for stdlib.h:
>      s/_GL_STDLIB_H/_GLINST_STDLIB_H/
>    Without it, strange things will happen when e.g. coreutils uses
>    stdlib.h from gnulib and its inclusion guard macro is the same as the
>    one of the installed stdlib.h.

I hadn't gotten that far yet, but yes, agreed.

>> 1. posix-modules vs strdup
>> --------------------------
>> The posix-modules script outputs both 'strdup' and 'strdup-posix' causing
>> a warning: 'This module is obsolete. But you may want to use the
>> strdup-posix module.'.
> 
> Is that a warning? I thought this was only a notice.
> 
>> I had to filter the out put of posix-modules to use omit strdup to prevent 
>> that.
> 
> You don't need to. Just ignore the notice.

It would be nicer still to have the posix-modules script not emit 'strdup'
though, no?

>> 2. posix-modules vs alloca
>> --------------------------
>> The modules specified by posix-modules require an LTALLOCA definition,
>> per 'libposix/Makefile.am:35: @LTALLOCA@ used but `LTALLOCA' is undefined'.
> 
> I think I fixed this last week.
>  
> <http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=cdd4444161dffa8759a201d71801787b64db42dc>

I think I may have caused that by also adding AC_FUNC_ALLOCA to configure.ac.
I'll reraise the issue if it happens again.

>> 3. missing AM_CONDITIONAL declarations
>> --------------------------------------
>> I suppose the following definitions are supposed to have been added to 
>> gl_INIT
>> somewhere, but `git grepping' around the gnulib sources didn't lead me to the
>> culprit.  
>> 
>> libposix/Makefile.am:4192: LIBUNISTRING_COMPILE_UNISTR_U8_MBTOUCR does not 
>> appear in AM_CONDITIONAL
>> libposix/Makefile.am:4200: LIBUNISTRING_COMPILE_UNISTR_U8_UCTOMB does not 
>> appear in AM_CONDITIONAL
>> libposix/Makefile.am:4240: LIBUNISTRING_COMPILE_UNIWIDTH_WIDTH does not 
>> appear in AM_CONDITIONAL
> 
> Strange, I haven't seen these. Can you prepare a real bug report (tarball with
> commands to execute) which shows this?

Definitely pilot error on my behalf.  Please disregard this one.

>> 4. pt_chown module
>> ------------------
>> gnulib/modules/pt_chown hardcodes libgnu.a, so I had to edit the gnulib
>> generated libposix/Makefile.am in libposix to refer to libposix.la instead.
> 
> Yes, this seems unavoidable. I don't see how a program's LDADD could refer to
> the library; what kind of syntax in the module description file would you
> suggest for this?

libgnu.a seems like a fine syntax already, and works well for --extract-xxx
options too.  I'd like to see gnulib-tool transform libgnu.a into whatever
is appropriate according to --lib and --libtool/--no-libtool arguments
without a manual post-gnulib-tool sed though.

>> 5. AC_USE_SYSTEM_EXTENSIONS references
>> --------------------------------------
>> This is just a warning, and doesn't prevent compilation so I didn't try to
>> figure out exactly how to fix a series of these warnings: 
>> 
>> configure.ac:12: warning: AC_COMPILE_IFELSE was called before 
>> AC_USE_SYSTEM_EXTENSIONS
>> ../../lib/autoconf/specific.m4:310: AC_GNU_SOURCE is expanded from...
>> m4/gnulib-comp.m4:22: GL_EARLY is expanded from...
>> configure.ac:12: the top levelconfigure.ac:12: warning: AC_RUN_IFELSE was 
>> called before AC_USE_SYSTEM_EXTENSIONS
>> ../../lib/autoconf/specific.m4:310: AC_GNU_SOURCE is expanded from...
>> m4/gnulib-comp.m4:22: GL_EARLY is expanded from...
>> configure.ac:12: the top levelconfigure.ac:12: warning: AC_COMPILE_IFELSE 
>> was called before AC_USE_SYSTEM_EXTENSIONS
>> ../../lib/autoconf/specific.m4:310: AC_GNU_SOURCE is expanded from...
>> m4/gnulib-comp.m4:22: GL_EARLY is expanded from...
>> configure.ac:12: the top levelconfigure.ac:12: warning: AC_RUN_IFELSE was 
>> called before AC_USE_SYSTEM_EXTENSIONS
>> ../../lib/autoconf/specific.m4:310: AC_GNU_SOURCE is expanded from...
>> m4/gnulib-comp.m4:22: GL_EARLY is expanded from...
>> configure.ac:12: the top level
> 
> The common way to get rid of these warnings is to insert an invocation of
> gl_USE_SYSTEM_EXTENSIONS at the appropriate place in configure.ac.

Seems like a kludge to me.  Either the AC_{RUN,COMPILE}_IFELSE using modules
should AC_REQUIRE_ONCE([gl_USE_SYSTEM_EXTENSIONS]) themselves, or AC_{RUN,
COMPILE}_IFELSE should invoke the require rather than the warning, no?  And
if that doesn't work, then AC_REQUIRE is not outputting macro expansions in
the right order.

What's the difference between AC_USE_SYSTEM_EXTENSIONS and gl_USE_SYSTEM_
EXTENSIONS?  The warnings seem to indicate that adding AC_REQUIRE([AC_
USE_SYSTEM_EXTENSIONS]) to AC_{RUN,COMPILE}_IFELSE is the right solution.

Cheers,
-- 
Gary V. Vaughan (address@hidden)

PGP.sig
Description: This is a digitally signed message part