[Top][All Lists]
[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
- Re: gnulib-tool feature request, (continued)
- Re: gnulib-tool feature request, Simon Josefsson, 2010/03/01
- Re: gnulib-tool feature request, Sam Steingold, 2010/03/01
- Re: gnulib-tool feature request, Simon Josefsson, 2010/03/01
- Re: gnulib-tool feature request, Sam Steingold, 2010/03/01
- Re: gnulib-tool feature request, Simon Josefsson, 2010/03/01
- Re: gnulib-tool feature request, Sam Steingold, 2010/03/01
- Re: gnulib-tool feature request, Simon Josefsson, 2010/03/01
- Re: gnulib-tool feature request, Sam Steingold, 2010/03/01
- Re: gnulib-tool feature request, Simon Josefsson, 2010/03/01
- Re: gnulib-tool feature request, Sam Steingold, 2010/03/01
- Re: gnulib-tool feature request,
Simon Josefsson <=
- Re: gnulib-tool feature request, Sam Steingold, 2010/03/02
- Re: gnulib-tool feature request, Simon Josefsson, 2010/03/02
- Re: gnulib-tool feature request, Sam Steingold, 2010/03/02