bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: installable gnulib library


From: Bruce Korb
Subject: Re: installable gnulib library
Date: Sun, 10 Oct 2010 08:00:09 -0700
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100714 SUSE/3.0.6 Thunderbird/3.0.6

Hi Gary,

On 10/10/10 02:14, Gary V. Vaughan wrote:
> I think your script is *much* more complicated than it needs to be.

Of course it is.  To properly understand 150+ lines of usage text
one needs to read the source and understand the intimate details
of libtool and autoconf.  I keep meaning to, but life gets in the way.

> Far easier to let the existing gnulib machinery populate an installable
> libposix project, surely? See below for my alternative two line script =)O|

Almost.  See below. ;)

> 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.....

That, or some mechanics for saying, "module X represents modules Y, Z, ..."
whereby libposix says it represents the posix module list.  This would
minimize the burden on gnulib clients (developers) to remember one more
thing.  I like reducing that burden, but it _is_ likely harder... :)

> 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.

The job of libposix is to reduce, as much as possible, the hassle of
adapting to different platforms.  Included in that is the difference
between last decade's POSIX and this or next decade's POSIX.  That said,
some mechanics for saying, "This function is deprecated" makes sense
for some sort of maintainer mode functionality -- similar to a link time
warning when someone binds to "mktemp(3)".

> ## configure.ac:
> 
> AC_INIT([libposix], [20101010], address@hidden)

The version will need to be computed :)

> 1. posix-modules vs strdup
> --------------------------
> The posix-modules script outputs both 'strdup' and 'strdup-posix' causing
> a warning: 'This module is obsolete....
>
> 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'.
> So I had to add the alloca module to the gnulib-tool invocation in bootstrap 
> above.

Yep, that's why this *HAS* to be tested all over the place.
That module is not needed when building on Linux....

> That feels like a kludge to me.
That feels like a *bug* to me. :)

> 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.

If it is a nuisance to fix, some script must create the correct "configure.ac"
anyway, so it may as well hack up libposix/Makefile.am if it is easier.
It's a one liner:
    sed -i "s/libgnu.a/${TARNAME}.la/" ${TARNAME}/Makefile.am
But actually, it has to be sedded or gnulib-tool must be augmented anyway.
Neither the library itself nor the header files are installed.
It would be useful to do that, too.  That is actually the bulk of the
functionality of my script (aside from infrastructure overhead).

> 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...

Here are my "make distcheck" results:

[...]
FAIL: test-dprintf-posix2.sh
[...]
FAIL: test-fprintf-posix3.sh
[...]
===================================
2 of 297 tests failed
Please report to address@hidden
===================================
make[5]: *** [check-TESTS] Error 1

I think it takes more than two lines.  :)  However, some of the options
you suggested do reduce the mv-s and sed-s a bit, so I will certainly
use those hints. Thank you.  Regards, Bruce



reply via email to

[Prev in Thread] Current Thread [Next in Thread]