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 11:15:21 +0100
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)

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.

Generally, the approach only seems to work if the gnulib modules used in
src/ are self-contained, i.e., enabling the module doesn't cause other
gnulib modules to behave differently.

Right now gnulib-tool doesn't know whether a module is "standalone" or
not -- but it could be encoded in the modules/ file.

So if you want to implement this approach, I think you need to add a new
field in the modules/ files 'Standalone: yes/no', and make gnulib-tool
only put modules with 'Standalone: yes' in the src/ directory.  Any
module that has 'Standalone: no', or any module with 'Standalone: yes'
but depends on any module with 'Standalone: no', must go into
modules/syscalls/ etc.  (Maintaining this information will be a pain
though.)

However, I'm not sure this will work out well.  I suspect the number of
gnulib modules that can be put into src/ and still work will be very
small.  A gnulib module that appear to be standalone may use some system
call that does not work well on some platform, and thus ends up
depending on that.  For example: malloc.  Then the otherwise standalone
module cannot be put in the core directory.

More ideas still welcome, or clarification if I'm missing something.  I
am experiencing problems in my projects over this gnulib design too (in
particular, slow ./configure.ac time because of duplciation, and code
duplication because all dependencies needs to be available in several
places) but haven't been able to come up with a solution that is
implementable.  Right now, I just let disk/CPU pay the price for this.
The runtime costs are quite small, if any, on any modern system.

/Simon




reply via email to

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