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
