bug-gnulib
[Top][All Lists]
Advanced

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

Re: gnulib-tool feature request


From: Simon Josefsson
Subject: Re: gnulib-tool feature request
Date: Tue, 02 Mar 2010 17:58:36 +0100
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)

Sam Steingold <address@hidden> writes:

> On 3/2/10, Simon Josefsson <address@hidden> wrote:
>> Sam Steingold <address@hidden> writes:
>>
>> > On 3/1/10, Simon Josefsson <address@hidden> wrote:
>>  >>
>>  >> It would be nice it gnulib-tool could do it, but I have a hard time
>>  >>  thinking how that would actually be implemented.  There are so many
>>  >>  different ways you may want to organize your gnulib directories that
>>  >>  having gnulib-tool support them all is probably going to overload the
>>  >>  poor shell script.  Concrete ideas are always welcome, though...
>>  >
>>  > gnulib-tool accepts --source-base and --m4-base as destination for files.
>>  > it should also accept --source-common and --m4-common which specify
>>  > the location of modules which are in the "core" of the project, i.e., 
>> which
>>  > can be assumed to be present.
>>  > So I will write something like:
>>  > gnulib-tool --source-base=src/gllib --m4-base=src/glm4 foo
>>  > gnulib-tool --source-common=src/gllib --m4-common=src/glm4
>>  >   --source-base=modules/syscalls/gllib --m4-base=modules/syscalls/glm4 bar
>>  > and if bar depends on foo, then foo files will not be added to
>>  > modules/syscalls/gllib
>>  > and modules/syscalls/glm4, instead they will be found in src/gllib & 
>> src/glm4
>>  > by the second invocation of gnulib-tool.
>>
>>
>> I don't think that approach works if modules/syscalls/ depends on a
>>  gnulib module (e.g., chown or malloc) that needs to modify a system
>>  header (i.e., unistd.h or stdlib.h) to work, and the system header is
>>  already in src/.  Unfortunately, that is a quite common pattern in
>>  gnulib.
>
> this is precisely why I wrote that --macro-prefix patch!

Maybe I'm beginning to slowly catch up...

> it would be not necessary if the --*-common arguments are introduced
> because then the macro prefix can be generated automatically.

But I don't see how it would work because of module interdependency's.
I think there are two main cases:

1) There is only one configure.ac that runs both gnulib m4 scripts in
   src/ and in the modules/foo/ directories.  (I'm using this model in
   GNU Libidn, Shishi and GSS.)

   You want the modules/foo/ directory to --avoid all modules from src/.

   This will result in one config.h, and it will be used both for the
   gnulib system-replacement header file in src/ and in the modules/foo/
   copy.  But it won't work well because a module in modules/foo/ may
   demand changes to a system header in src/ that will break for
   modules/bar/.  For example, consider if modules/foo/ replaces system
   function FOO declared in src/stdlib.h because it needs some
   particular behaviour from FOO that's not widely needed.  Anything
   #include'ing the src/ header files will get the same replacement, and
   things will break because modules/bar/ doesn't link to modules/foo/'s
   gnulib library that provides rpl_FOO.

2) There are two configure.ac that has its own gnulib m4 scripts.  (I'm
   using this model in GnuTLS and GNU SASL.)

   You want the modules/foo/ directory to --avoid all modules from src/.

   This will result in two config.h files and two _different_ system
   replacement header files.  The system replacement header files will
   provide conflicting definitions.  For example, if sys_socket.h is in
   both src/ and modules/foo/ and modules/foo/ provides a declaration of
   struct sockaddr_storage, the #include_next that points to the src/
   copy also provides the same declaration, you'll get an error.

Which of these cases are you considering?  Or something else?

>>  Right now, I just let disk/CPU pay the price for this.
>>  The runtime costs are quite small, if any, on any modern system.
>
> 1. how about embedded systems?
>
> 2. I find this approach to be highly unaesthetic.
> One of the reasons we do FLOSS in our copious spare time is
> the desire to _reduce_ the ugliness - and when clisp has to be distributed
> with _several_ copies of most of gnu libc is ugly to the extreme.

Sure.  I'm not sure how to resolve it though, without shipping the
_entire_ glibc code together with all packages and make sure that the
glibc replacement is built and used by all the remaining code that may
need different parts of the glibc code.

/Simon




reply via email to

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