bug-gnulib
[Top][All Lists]
Advanced

[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)

Attachment: PGP.sig
Description: This is a digitally signed message part


reply via email to

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