[PATCH] Do not include and in same file

[Craig Rodrigues <ro...@crodrigues.org>]

Hi,

I maintain the port of APR for the FreeBSD ports system.
I was assigned the following bug:

http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/88406

If e2fsprogs is installed on a FreeBSD 5.4 system,
compilation of APR fails, because types conflict
if <uuid.h> (from the system) and <uuid/uuid.h> (from e2fsprogs) are
both included.

<uuid.h> is a relatively recent addition to FreeBSD and
was added in the FreeBSD 5.x timeframe.

Is this patch acceptable for apr?

Index: rand.c
===================================================================
--- rand.c	(revision 330355)
+++ rand.c	(working copy)
@@ -35,11 +35,10 @@
 #if APR_HAVE_SYS_UN_H
 #include <sys/un.h>
 #endif
-#ifdef HAVE_UUID_UUID_H
-#include <uuid/uuid.h>
-#endif
 #ifdef HAVE_UUID_H
 #include <uuid.h>
+#elif defined(HAVE_UUID_UUID_H)
+#include <uuid/uuid.h>
 #endif
 
 #ifndef SHUT_RDWR

-- 
Craig Rodrigues        
rodrigc@crodrigues.org

Re: [PATCH] Do not include and in same file

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Graham Leggett wrote:
> 
> But regardless, a build tool needs to do at least this:
> 
> - Track dependancies properly. If changing a header file does not cause 
> corresponding rebuild of code, the build system is broken.
> 
> - Be as platform independant as possible. Here autoconf scores lots of 
> points by having had wide exposure and a long history.
> 
> - Be reasonably straightforward to use. Here autoconf is not as clear, 
> but we did find that a lot of clarity comes from creating your 
> configure.ac's in as standard a way as possible.

wrowe pines += 3

I'd disagree autoconf scores points, in fact it's gone negative in my book.
Simple fact is that automake (not our issue) autoconf m4 and libtool have proven
very slippery targets.  Yes; solaris, linux, bsd get points here.  AIX, HPUX,
Tru64 and many others show up significant flukes with autoconf.  It's toolchain
is rather long in terms of packages that must be present (especially odd sed
prerequisites.)  And the fact that only bash is well supported is another minus,
since plenty of boxes shipped with ksh or others.

shell-as-a-language is a major weakness for a build system :(

Bill

Re: [PATCH] Do not include and in same file

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Max Bowsher wrote:
> 
> Another benefit of autoconf is the interface presented to users - a
> ./configure script - is such a familiar and ubiquitous one.

Another pine += 1; I'd say that anything that doesn't get us to a "please
do x, y, z, and please omit a, b" from the command line will be a problem.
Autoconf's command line syntax sets a rather good example to use.

Re: [PATCH] Do not include and in same file

[Max Bowsher <ma...@ukf.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

William A. Rowe, Jr. wrote:
> Max Bowsher wrote:
>> 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.

- From the tags in FreeBSD cvsweb, it looks like:

uuid_create() in libc added in 5.0
e2fsprogs port added in 4.4

Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)

iD8DBQFEAjPCfFNSmcDyxYARAhp8AJ4vfv7fkoi3dSdkZKDEq9hJwIbm7QCfc4Ai
6bDizIwBipReRkrq5LocZ9Q=
=e27+
-----END PGP SIGNATURE-----

Re: [PATCH] Do not include and in same file

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Max Bowsher wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Garrett Rooney wrote:
> 
>>On 2/23/06, Max Bowsher <ma...@ukf.net> 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

Re: [PATCH] Do not include and in same file

[Garrett Rooney <ro...@electricjellyfish.net>]

On 2/25/06, Max Bowsher <ma...@ukf.net> wrote:

> 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

-garrett

Re: [PATCH] Do not include and in same file

[Max Bowsher <ma...@ukf.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Garrett Rooney wrote:
> On 2/23/06, Max Bowsher <ma...@ukf.net> 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.


Max.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)

iD8DBQFEAJWSfFNSmcDyxYARAsVwAJ9ganHohbzOqsdizCoYa5gjhhxL7QCglcyD
CnTAPVCl4m7QRPetMGzO2qQ=
=AF3y
-----END PGP SIGNATURE-----

Re: [PATCH] Do not include and in same file

[Garrett Rooney <ro...@electricjellyfish.net>]

On 2/23/06, Max Bowsher <ma...@ukf.net> 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.

-garrett

Re: [PATCH] Do not include and in same file

[Max Bowsher <ma...@ukf.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Graham Leggett wrote:
> William A. Rowe, Jr. wrote:
> 
>>> My gut says if we cannot solve this trivial problem over the
>>> course of three+ months due to a utter lack of competency in
>>> autoconf (and lack of time by the small handful who understand
>>> it), perhaps the project should consider alternatives to autoconf
>>> as we start looking down the road at APR 2.0.0?
>>>
>>> Does anyone have any positive experiences with other configuration
>>> and feature detection tools?
> 
> I recently had to get my hands dirty getting a 17 year old combination C
> and C++ codebase cleaned up and the build system replaced from scratch,
> and in the process got quite good at doing autoconf + automake +
> libtool. We kept the config pretty standard, and found that as long as
> you keep things simple and straightforward autoconf works pretty well.
> 
> But regardless, a build tool needs to do at least this:
> 
> - Track dependancies properly. If changing a header file does not cause
> corresponding rebuild of code, the build system is broken.
> 
> - Be as platform independant as possible. Here autoconf scores lots of
> points by having had wide exposure and a long history.
> 
> - Be reasonably straightforward to use. Here autoconf is not as clear,
> but we did find that a lot of clarity comes from creating your
> configure.ac's in as standard a way as possible.

Another benefit of autoconf is the interface presented to users - a
./configure script - is such a familiar and ubiquitous one.

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.

Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)

iD8DBQFD/hJlfFNSmcDyxYARAuMDAKDE4bfM5NgNWkk1r3ZeuXV9KlQAVwCfUZeY
Z3v2ugKuU9nqdfbdK+OeY58=
=Ok2r
-----END PGP SIGNATURE-----

Re: [PATCH] Do not include and in same file

[Graham Leggett <mi...@sharp.fm>]

William A. Rowe, Jr. wrote:

>> My gut says if we cannot solve this trivial problem over the course of 
>> three+
>> months due to a utter lack of competency in autoconf (and lack of time by
>> the small handful who understand it), perhaps the project should consider
>> alternatives to autoconf as we start looking down the road at APR 2.0.0?
>>
>> Does anyone have any positive experiences with other configuration and 
>> feature
>> detection tools?

I recently had to get my hands dirty getting a 17 year old combination C 
and C++ codebase cleaned up and the build system replaced from scratch, 
and in the process got quite good at doing autoconf + automake + 
libtool. We kept the config pretty standard, and found that as long as 
you keep things simple and straightforward autoconf works pretty well.

But regardless, a build tool needs to do at least this:

- Track dependancies properly. If changing a header file does not cause 
corresponding rebuild of code, the build system is broken.

- Be as platform independant as possible. Here autoconf scores lots of 
points by having had wide exposure and a long history.

- Be reasonably straightforward to use. Here autoconf is not as clear, 
but we did find that a lot of clarity comes from creating your 
configure.ac's in as standard a way as possible.

Regards,
Graham
--

Re: [PATCH] Do not include and in same file

[Martin Sebor <se...@roguewave.com>]

William A. Rowe, Jr. wrote:
> My gut says if we cannot solve this trivial problem over the course of 
> three+
> months due to a utter lack of competency in autoconf (and lack of time by
> the small handful who understand it), perhaps the project should consider
> alternatives to autoconf as we start looking down the road at APR 2.0.0?
> 
> Does anyone have any positive experiences with other configuration and 
> feature
> detection tools?

We (stdcxx) have been using our own very simple yet quite powerful
autoconfiguration infrastructure. It's not as efficient as autoconf
but it's easier to understand and work with, and the inefficiency
could easily be dealt with.

The whole thing is only about 350 lines of shell script embedded in
just one GNU makefile, with the configuration tests stored separately
as plain C/C++ source and/or shell scripts:

http://svn.apache.org/repos/asf/incubator/stdcxx/trunk/etc/config/GNUmakefile.cfg
http://svn.apache.org/repos/asf/incubator/stdcxx/trunk/etc/config/src/

The basic types of config tests the infrastructure can do:

    compile only
    compile, link and run
    compile, link, run, and collect output
    compile and link a library
    compile and link with an object or library

 From what I understand, autoconf doesn't do the last three. The
downside is that there is no libtool.

Martin

Re: [PATCH] Do not include and in same file

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

My gut says if we cannot solve this trivial problem over the course of three+
months due to a utter lack of competency in autoconf (and lack of time by
the small handful who understand it), perhaps the project should consider
alternatives to autoconf as we start looking down the road at APR 2.0.0?

Does anyone have any positive experiences with other configuration and feature
detection tools?

Bill


William A. Rowe, Jr. wrote:
> Well one mystery is solved.  Folks experiencing build breakage likely have
> installed python2.4, which deposits libuuid into /usr/local/lib, without
> any corresponding header file.
> 
> We have only one election to use osuuid, and that is a bogus test for 
> the lib.
> The proper test must check that the uuid_t resolves, and generate_uuid 
> can be
> invoked without compile warnings, no matter if it is declared in uuid.h,
> uuid/uuid.h, or somewhere in the bowels of unistd.h or other common system
> header files.
> 
> Throwing the yes/no flag on the linkability of generate_uuid against -luuid
> or the clib is pretty broken behavior.
> 
> Bill
> 
> Garrett Rooney wrote:
> 
>> On 2/14/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>>
>>> Garrett Rooney wrote:
>>>
>>>> On 11/2/05, Craig Rodrigues <ro...@crodrigues.org> wrote:
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> I maintain the port of APR for the FreeBSD ports system.
>>>>> I was assigned the following bug:
>>>>>
>>>>> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/88406
>>>>>
>>>>> If e2fsprogs is installed on a FreeBSD 5.4 system,
>>>>> compilation of APR fails, because types conflict
>>>>> if <uuid.h> (from the system) and <uuid/uuid.h> (from e2fsprogs) are
>>>>> both included.
>>>>>
>>>>> <uuid.h> is a relatively recent addition to FreeBSD and
>>>>> was added in the FreeBSD 5.x timeframe.
>>>>>
>>>>> Is this patch acceptable for apr?
>>>>
>>>>
>>>>
>>>> Looks good to me, committed in r355780.
>>>>
>>>> Sorry for the delay, this has been sitting in my inbox forever and I
>>>> just got a chance to try it out.
>>>
>>>
>>> Could this commit be the origin of breakage on Macintosh OS/X?  Both 
>>> 1.2.x
>>> and trunk fail to compile on Darwin7.9.0 kernel at this moment.
>>
>>
>>
>> AFAIK this patch was never merged into 1.2.x, so if you're having
>> trouble building 1.2.x it's probably something else.
>>
>> -garrett
>>
>>
> 
> 
> 

Re: [PATCH] Do not include and in same file

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Well one mystery is solved.  Folks experiencing build breakage likely have
installed python2.4, which deposits libuuid into /usr/local/lib, without
any corresponding header file.

We have only one election to use osuuid, and that is a bogus test for the lib.
The proper test must check that the uuid_t resolves, and generate_uuid can be
invoked without compile warnings, no matter if it is declared in uuid.h,
uuid/uuid.h, or somewhere in the bowels of unistd.h or other common system
header files.

Throwing the yes/no flag on the linkability of generate_uuid against -luuid
or the clib is pretty broken behavior.

Bill

Garrett Rooney wrote:
> On 2/14/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> 
>>Garrett Rooney wrote:
>>
>>>On 11/2/05, Craig Rodrigues <ro...@crodrigues.org> wrote:
>>>
>>>
>>>>Hi,
>>>>
>>>>I maintain the port of APR for the FreeBSD ports system.
>>>>I was assigned the following bug:
>>>>
>>>>http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/88406
>>>>
>>>>If e2fsprogs is installed on a FreeBSD 5.4 system,
>>>>compilation of APR fails, because types conflict
>>>>if <uuid.h> (from the system) and <uuid/uuid.h> (from e2fsprogs) are
>>>>both included.
>>>>
>>>><uuid.h> is a relatively recent addition to FreeBSD and
>>>>was added in the FreeBSD 5.x timeframe.
>>>>
>>>>Is this patch acceptable for apr?
>>>
>>>
>>>Looks good to me, committed in r355780.
>>>
>>>Sorry for the delay, this has been sitting in my inbox forever and I
>>>just got a chance to try it out.
>>
>>Could this commit be the origin of breakage on Macintosh OS/X?  Both 1.2.x
>>and trunk fail to compile on Darwin7.9.0 kernel at this moment.
> 
> 
> AFAIK this patch was never merged into 1.2.x, so if you're having
> trouble building 1.2.x it's probably something else.
> 
> -garrett
> 
> 

Re: [PATCH] Do not include and in same file

[Garrett Rooney <ro...@electricjellyfish.net>]

On 2/14/06, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Garrett Rooney wrote:
> > On 11/2/05, Craig Rodrigues <ro...@crodrigues.org> wrote:
> >
> >>Hi,
> >>
> >>I maintain the port of APR for the FreeBSD ports system.
> >>I was assigned the following bug:
> >>
> >>http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/88406
> >>
> >>If e2fsprogs is installed on a FreeBSD 5.4 system,
> >>compilation of APR fails, because types conflict
> >>if <uuid.h> (from the system) and <uuid/uuid.h> (from e2fsprogs) are
> >>both included.
> >>
> >><uuid.h> is a relatively recent addition to FreeBSD and
> >>was added in the FreeBSD 5.x timeframe.
> >>
> >>Is this patch acceptable for apr?
> >
> >
> > Looks good to me, committed in r355780.
> >
> > Sorry for the delay, this has been sitting in my inbox forever and I
> > just got a chance to try it out.
>
> Could this commit be the origin of breakage on Macintosh OS/X?  Both 1.2.x
> and trunk fail to compile on Darwin7.9.0 kernel at this moment.

AFAIK this patch was never merged into 1.2.x, so if you're having
trouble building 1.2.x it's probably something else.

-garrett

Re: [PATCH] Do not include and in same file

["William A. Rowe, Jr." <wr...@rowe-clan.net>]

Garrett Rooney wrote:
> On 11/2/05, Craig Rodrigues <ro...@crodrigues.org> wrote:
> 
>>Hi,
>>
>>I maintain the port of APR for the FreeBSD ports system.
>>I was assigned the following bug:
>>
>>http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/88406
>>
>>If e2fsprogs is installed on a FreeBSD 5.4 system,
>>compilation of APR fails, because types conflict
>>if <uuid.h> (from the system) and <uuid/uuid.h> (from e2fsprogs) are
>>both included.
>>
>><uuid.h> is a relatively recent addition to FreeBSD and
>>was added in the FreeBSD 5.x timeframe.
>>
>>Is this patch acceptable for apr?
> 
> 
> Looks good to me, committed in r355780.
> 
> Sorry for the delay, this has been sitting in my inbox forever and I
> just got a chance to try it out.

Could this commit be the origin of breakage on Macintosh OS/X?  Both 1.2.x
and trunk fail to compile on Darwin7.9.0 kernel at this moment.

Bill

Re: [PATCH] Do not include and in same file

[Garrett Rooney <ro...@electricjellyfish.net>]

On 11/2/05, Craig Rodrigues <ro...@crodrigues.org> wrote:
> Hi,
>
> I maintain the port of APR for the FreeBSD ports system.
> I was assigned the following bug:
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/88406
>
> If e2fsprogs is installed on a FreeBSD 5.4 system,
> compilation of APR fails, because types conflict
> if <uuid.h> (from the system) and <uuid/uuid.h> (from e2fsprogs) are
> both included.
>
> <uuid.h> is a relatively recent addition to FreeBSD and
> was added in the FreeBSD 5.x timeframe.
>
> Is this patch acceptable for apr?

Looks good to me, committed in r355780.

Sorry for the delay, this has been sitting in my inbox forever and I
just got a chance to try it out.

-garrett