[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: installable gnulib library
From: |
Gary V. Vaughan |
Subject: |
Re: installable gnulib library |
Date: |
Mon, 11 Oct 2010 09:19:27 +0700 |
[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
- Re: installable gnulib library, (continued)
- Re: installable gnulib library, Bruno Haible, 2010/10/10
- Re: installable gnulib library, Gary V. Vaughan, 2010/10/11
- possible USE_SYSTEM_EXTENSIONS bug [was: installable gnulib library], Eric Blake, 2010/10/11
- Re: installable gnulib library, Bruce Korb, 2010/10/10
- Re: installable gnulib library, Bruno Haible, 2010/10/10
- Re: installable gnulib library, Bruce Korb, 2010/10/10
- Re: installable gnulib library,
Gary V. Vaughan <=
- Re: installable gnulib library, Gary V. Vaughan, 2010/10/10
- Re: installable gnulib library, Gary V. Vaughan, 2010/10/10
- Re: installable gnulib library, Eric Blake, 2010/10/11
- Re: installable gnulib library, Bruce Korb, 2010/10/10
- Re: dprintf, fprintf memory leak, Bruno Haible, 2010/10/10
- Re: installable gnulib library, Gary V. Vaughan, 2010/10/10
- Re: installable gnulib library, Bruce Korb, 2010/10/11
- Re: installable gnulib library, Gary V. Vaughan, 2010/10/11
- Re: installable gnulib library, Gary V. Vaughan, 2010/10/09
Re: installable gnulib library, Bruce Korb, 2010/10/10