bug-gnulib
[Top][All Lists]
Advanced

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

Re: first draft of "relocatable" module


From: Ben Pfaff
Subject: Re: first draft of "relocatable" module
Date: Sun, 25 Feb 2007 18:27:42 -0800
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)

Bruno Haible <address@hidden> writes:

> In gnulib we have two kinds of documentation: 1. Doc for the end-user,
> copied into the using package and therefore mentioned in the module
> description, and 2. Doc for the programmer or maintainer.
> So far you've got doc #2. There is also a couple of paragraphs for the
> user (discussing --enable-relocatable, --prefix etc.) in
>   http://lists.gnu.org/archive/html/bug-gnulib/2003-03/msg00020.html
> that you could copy into doc #1.

OK.  Now I've put essentially that text into
doc/relocatable.texi, with part of the introduction from what was
there before, and added doc/relocatable.texi to the module
description.  Then I moved the previous text into new file
doc/relocatable-maint.texi.

I updated the description in relocatable-maint.texi a bit from
Ralf Wildenhues's comments, but I'm waiting on clarification from
him to do more there.

>>         * progreloc.c needed to be updated for the changed
>>           xreadlink interface.
>
> The xreadlink interface needs Jim's opinion. The <unistd.h> change is ok.

OK.

>>         * relocatable.c is from gettext, but I was able to take
>>           advantage of new gnulib modules to drop quite a bit of
>>           boilerplate from the beginning.  Perhaps my use of the
>>           c-ctype module will be rejected, but I hope that the
>>           rest is not controversial.
>
> However, relocatable.c is also used in libraries that are made
> relocatable. This is more complicated than the case of relocatable programs,
> but with some care I was able use the same code. In particular, libintl
> uses this code, and it is thus copied into every package that uses
> "gettextize --intl" (e.g. grep or binutils). Therefore here I find it good
> to avoid dependencies to too many gnulib files. Especially dependencies to
> GPLed modules, since relocatable.c must be LGPL for libintl to include it.
>
> Therefore here I'm against the use of <stdbool.h>, filename.h, and xalloc.h.

OK, I reverted these parts.

> Also I didn't see where you moved the _GNU_SOURCE setting to.

I depended on the "extensions" module, which calls AC_GNU_SOURCE.
Do you prefer to #define _GNU_SOURCE explicitly in the source file?

>>           Ditto for relocatable.m4.
>
> Where did the AC_EXEEXT invocation go?

Autoconf 2.50 had this item in its NEWS:

    - AC_EXEEXT, AC_OBJEXT
      You are no longer expected to use them: their computation is
      performed by default.

and AC_EXEEXT is listed in the "Obsolete Macros" section of the
Autoconf manual.  So it seemed safe to drop it.

>>         * relocatable.sh.in is an extract from gettext's
>>           gettextize.sh.in explained in relocatable.texi.
>
> OK. But the largest part of this shell script code is not to be modified
> by the maintainer. Can you make this code available through a single
> autoconf variable (assuming autoconf-2.61) or through some Makefile.am
> rule? For the part which contains the variables needed by the script,
> this is obviously not fully automatable on the gnulib side; documenting
> the customization/adaptation steps, like you did, is fine.

OK, done.

>>         * I wrote modules/relocatable myself.
>
> This is GPL, but libraries need part of it under LGPL, namely: relocatable.h,
> relocatable.c, and the macros AC_RELOCATABLE_LIBRARY and AC_RELOCATABLE_NOP
> from relocatable.m4? Can you group them into a module 'relocatable-lib'
> that 'relocatable' depends upon?

OK, done.

> I'm not sure whether then it's also worth making a separate
> 'relocatable-script' module that takes care of the mechanics for the
> relocatable shell scripts?

Yes, I think so: if we're going to be copying in an extra file
(lib/relocatable.sh.in) for that case, then we might as well make
it separate to avoid the need in packages that do not install any
shell scripts.  Done.

>> Now, my questions, which I hope do not sound too stupid:
>> 
>>         * First, the Automake variables required for
>>           relocatability.  It seems like three of these
>>           (RELOCATABLE_SRC_DIR, RELOCATABLE_BUILD_DIR,
>>           RELOCATABLE_CONFIG_H_DIR) are completely mechanical and
>>           that they could just be produced by AC_RELOCATABLE and
>>           AC_SUBST'd.  Any reason not to do that?
>
> Yes, good point. This is possible. You can refer to $(top_srcdir) and
> $(top_builddir).

OK, done.

>>         * It seems that $(libdir) is a reasonable default for
>>           RELOCATABLE_LIBRARY_PATH.  Is it reasonable to make
>>           this an optional argument to AC_RELOCATABLE and use
>>           $(libdir) as the default?
>
> The idea of having a default is good. What should the default be? In
> simple cases, such as GNU hello, the package installs only programs, not
> libraries. Therefore I think the default should be empty. (GNU gettext uses
> $(libdir), because it's there that it installs libintl.so.)

OK, done.

>>         * @SET_RELOCATABLE@ just expands to a variable
>>           definition.  Do we need this extra level of
>>           indirection?
>
> What could you simplify here? I don't see it.

I mean, why not do this:

    @@ -40,8 +52,9 @@
           mingw*) is_noop=yes ;;
           linux*) use_elf_origin_trick=yes ;;
         esac
         if test $is_noop = yes; then
    -      SET_RELOCATABLE="RELOCATABLE_LDFLAGS = :"
    +      RELOCATABLE_LDFLAGS=:
    +      AC_SUBST([RELOCATABLE_LDFLAGS])
         else
           if test $use_elf_origin_trick = yes; then
             dnl Use the dynamic linker's support for relocatable programs.

and so on.  It seems to work.  Am I missing something?

>>         * The suggested method of setting INSTALLDIR uses a
>>           program-specific variable.  I think that this prevents
>>           sharing object files between programs, increasing the
>>           number of compilations necessary if programs share
>>           source files.
>
> Yes, I think so too.
>
>>           If so, should we instead generate a .c
>>           file that defines orig_installdir and
>>           orig_installprefix?
>
> An interesting idea. I would say yes if it doesn't increase the number of
> variables to be declared manually in the Makefile.am. If it causes hassles
> to the package maintainer, however, I'd say no - since we're talking only
> about an optimization.

I'm going to sit on this idea until we hear from Ralf about his
suggestions for Automake support.

>>         * Should I rename AC_RELOCATABLE to gl_RELOCATABLE?
>
> Yes please. I'm no longer following the goal of pushing this into autoconf.
> Therefore 'gl_' is the right prefix.

Done.

I'm attaching updated sets of diffs, same ones as before.

Attachment: relocatable2.patch
Description: gnulib diffs for relocatability

Attachment: gnulib-vs-gettext.diff
Description: gnulib diff versus gettext

Attachment: relocatable-hello2.patch
Description: hello patch for relocatability

-- 
Only wimps use tape backup: _real_ men just upload their important stuff
on ftp, and let the rest of the world mirror it ;)
        -- Linus Torvalds

reply via email to

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