Max Bowsher wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Garrett Rooney wrote:
On 2/23/06, Max Bowsher <[EMAIL PROTECTED]> wrote:
Another benefit of autoconf is the interface presented to users - a
./configure script - is such a familiar and ubiquitous one.
+1
I'd rate myself as competent with autoconf+libtool, and am happy to help
- - feel free to prod me explicitly towards any issues requiring an
autotool-interested person if I don't notice myself.
Fixing the libuuid detection so that it doesn't try to use libuuid if
it can't find the appropriate header files seems to be the current
problem. Bill Rowe's got a system where libuuid exists, but uuid.h
and uuid/uuid.h don't, so we end up trying to use the uuid code
without the appropriate structure definitions, with predictable
results.
OK, I've looked into the situation - looks simple enough to fix: just
tweaking the logic so we only enable apr_os_uuid_get if we find both a
linkable function and a header.
I've found that the patch that started this thread and committed in
r355780 actually doesn't work - the build still dies, because it tries
to use compile code using one uuid implementation using the header of
the other - I'll fix this.
I have one question: if *both* uuid implemenations are available, which
one should we prefer? The options are:
DCE/BSD <uuid.h> uuid_create() libc
e2fsprogs <uuid/uuid.h> uuid_generate() libuuid
I'm inclined to prefer the one in libc, in order to minimize dependencies.
+++1; my only question is how long has it been available, e.g., was it slipped
in midstream on BSD or if we say (for example) it's a BSD 4.4 binary, we know
it's available in libc throughout that release? I'd think libuuid would be
a fallthough for platforms where it's available, and uuid_create is not. But
like our long history with libexpat, detecting and rolling with it can prove
troublesome when the resulting package is installed on a box without the lib.
Bill