[Top][All Lists]
[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.
relocatable2.patch
Description: gnulib diffs for relocatability
gnulib-vs-gettext.diff
Description: gnulib diff versus gettext
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
Re: first draft of "relocatable" module, Albert Chin, 2007/02/28