Re: libposix build logs

[Bruce Korb]

Hi Ralf,

On 01/02/11 04:44, Ralf Wildenhues wrote:
>> I think the main hangout item is now just that autoconf macro.
>> I would guess looking for version.h in /usr/local/include/libposix
>> then /usr/include/libposix and provide a --with-libposix=/path.
> 
> Well, the autoconfy way would be to not look for a version number,
> but for a feature (API function or so) that you need.

That is, indeed, the autoconfy way to do it.  Were gnulib versions
a tree instead of linearly progressed, you would need feature tests.
Then you would need a forest of feature tests to ensure that
everything you need is, in fact, implemented in the destination
platform's libposix.  Two points:

* The main goal of libposix is the simplification of config tests
  (both for developer complexity and configure probing delays).

* Given the linearity, once a developer determines which version
  covers all the relevant features, the developer should be able
  to rely on those features on all successive versions.  I think
  that is one of the points of gnulib.

  If it becomes impossible to support one feature because of
  changes to posix requirements, then we will have to figure
  out a way across that bridge.  I'd rather not presuppose it
  now.

> Or you could use pkg-config.
> Me ducks and runs,

That may be like floating a lead balloon, Myth Busters not
withstanding....

> Ralf (haven't dug through the program_error_name stuff yet)

My solution is to disable the error() calls from "*-die" modules
that get called from posix modules.  Once error() is POSIX-safe
(does not require a set_program_name() call), then the disablement
can be disabled (removed).  I've already pushed the disabling into
two die modules: xalloc-die and openat-die.  They are the only
libposix modules that reference the error module.

> wishing a happy gnu year ...

Likewise, Happy Hew Year.  Cheers - Bruce