[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 4/7] New module `libposix'.
From: |
Gary V. Vaughan |
Subject: |
Re: [PATCH 4/7] New module `libposix'. |
Date: |
Wed, 13 Oct 2010 17:02:04 +0700 |
On 13 Oct 2010, at 03:43, Bruno Haible wrote:
>> Making libposix into a module makes life considerably easier.
>
> Yes, it triggers the magic that tells gnulib-tool to omit the augmentation of
> noinst_LIBRARIES.
>
> But I don't agree with putting the module list here. Who will keep it
> up-to-date?
Who keeps the documentation in the posix .texi docs up-to-date? It is
hardly any extra work to put an extra line in modules/libposix when
adding a new module to the .texi sources. Also, I added an awk script
to libposix/bootstrap so that every-time someone makes a new release
of libposix (or even just builds libposix in-situ for their own
purposes), they are given a list of differences between the output
of posix-modules and `gnulib-tool --extract-dependencies libposix`.
I could wrap in ${bold_on}/${bold_off} to draw more attention to
that list if you'd like?
> The maintainable solution is to use `./posix-modules`. But how?
> Either
> a) extend gnulib-tool so that it understands
> Depends-on:
> `./posix-modules`
> and invokes the 'posix-modules' script.
I agree, Ick!
> Or
> b) Invoke ../posix-modules in the bootstrap script of the 'libposix'
> subdirectory.
Also, Ick!
> For the moment, I would prefer solution b), because it would slow down every
> lookup of dependencies in gnulib-tool, and because evaluating shell commands
> here and there can be seen as a security problem in some contexts.
While I understand your reasoning, I rather dislike the idea of having
libposix/bootstrap run `posix-modules` and edit the output, along with
any other tweaking that might turn out to be necessary to workaround not
treating the libposix module as a first-class gnulib module. It seems
like busy work, where maintaining a static list of libposix dependencies
in the libposix module is cleaner and no more difficult.
Why not make the Depends On: section of this libposix module the master
copy of the modules that will go into libposix (not quite identical to
the output of posix-modules - since I removed strdup [arguably a
premature optimisation], and added alloca and progname for reasons already
discussed). The posix-modules script would then be simplified to
`gnulib-tool --extract-dependencies libposix`.
Actually, I'm not really sure why posix-modules exists at all. Perhaps
than's why I still disagree here. What is the use case for posix-modules?
Cheers,
--
Gary V. Vaughan (address@hidden)
PGP.sig
Description: This is a digitally signed message part
[PATCH 1/7] gnulib-tool: transform include guards with `--macro-prefix', Gary V. Vaughan, 2010/10/12