When to use HAVE_XXX_H or APR_HAVE_XXX_H

[Rainer Jung <ra...@kippdata.de>]

When compiling mod_ftp 0.9.5 I ran into the problem, that is was using
APR_HAVE_SYS_STAT_H instead of HAVE_SYS_STAT_H.

I saw in configure.in, that apr tests for a lot of headers, but it
doesn't set an APR_HAVE_* define for all of them in apr.h.in.

In the case of sys/stat.h this leads to the situation, that code uses
APR_HAVE_SYS_STAT_H although it seems it is never defined. Even some
files in apr itself use this define. Other files in apr use HAVE_SYS_STAT_H.

Is there some policy, when to use APR_HAVE_* defines for testing the
includes and when to use the HAVE_* type defines?

Regards,

Rainer

Re: When to use HAVE_XXX_H or APR_HAVE_XXX_H

[Rainer Jung <ra...@kippdata.de>]

On 17.09.2009 20:23, William A. Rowe, Jr. wrote:
> Rainer Jung wrote:
>> When compiling mod_ftp 0.9.5 I ran into the problem, that is was using
>> APR_HAVE_SYS_STAT_H instead of HAVE_SYS_STAT_H.
>>
>> I saw in configure.in, that apr tests for a lot of headers, but it
>> doesn't set an APR_HAVE_* define for all of them in apr.h.in.
> 
> That is correct.  For compatibility, we can introduce any that we believe
> are useful into apr 2.0, but not apr 1.3.  The rule of thumb, IIRC, was that
> headers *we need* to include within our public headers must be "exported"
> with APR_HAVE_ symbols.  Those which we consume internally are just that,
> internal only.
> 
> Of course, folks applied different thumbs, so I don't know that this was
> done consistently.
> 
>> In the case of sys/stat.h this leads to the situation, that code uses
>> APR_HAVE_SYS_STAT_H although it seems it is never defined. Even some
>> files in apr itself use this define. Other files in apr use HAVE_SYS_STAT_H.
>>
>> Is there some policy, when to use APR_HAVE_* defines for testing the
>> includes and when to use the HAVE_* type defines?
> 
> The immediate solution for your problem was to yank the faulty APR_HAVE test
> that never existed, and add an application test.
> 
> Long term, we aught to decide if what's described above was policy;
> if so, perhaps we should document it?  If not, perhaps we should add
> APR_HAVE_SYS_STAT_H for apr 2.0 (even for 1.4)?

Thanks Bill and Jeff, I hope I got it.

As an example in the mod_ftp case the places that need to test for
header inclusion are totally independent of apr, they go directly down
to the system API, so there we should use the HAVE_* variant.

It seems there's no need for APR to really export APR_SYS_STAT_H. The
use of it is in three files

file_io/unix/mktemp.c:77:#if APR_HAVE_SYS_STAT_H
file_io/win32/open.c:29:#if APR_HAVE_SYS_STAT_H
file_io/win32/pipe.c:29:#if APR_HAVE_SYS_STAT_H

and the reason seems to be more an attempt of cleaning up unconditional
includes observed when fixing something else:

http://svn.eu.apache.org/viewvc?view=rev&revision=62952
http://svn.eu.apache.org/viewvc?view=rev&revision=62955
http://svn.eu.apache.org/viewvc?view=rev&revision=62956

All of those go back to 2002.

Regards,

Rainer

Re: When to use HAVE_XXX_H or APR_HAVE_XXX_H

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

Rainer Jung wrote:
> When compiling mod_ftp 0.9.5 I ran into the problem, that is was using
> APR_HAVE_SYS_STAT_H instead of HAVE_SYS_STAT_H.
> 
> I saw in configure.in, that apr tests for a lot of headers, but it
> doesn't set an APR_HAVE_* define for all of them in apr.h.in.

That is correct.  For compatibility, we can introduce any that we believe
are useful into apr 2.0, but not apr 1.3.  The rule of thumb, IIRC, was that
headers *we need* to include within our public headers must be "exported"
with APR_HAVE_ symbols.  Those which we consume internally are just that,
internal only.

Of course, folks applied different thumbs, so I don't know that this was
done consistently.

> In the case of sys/stat.h this leads to the situation, that code uses
> APR_HAVE_SYS_STAT_H although it seems it is never defined. Even some
> files in apr itself use this define. Other files in apr use HAVE_SYS_STAT_H.
> 
> Is there some policy, when to use APR_HAVE_* defines for testing the
> includes and when to use the HAVE_* type defines?

The immediate solution for your problem was to yank the faulty APR_HAVE test
that never existed, and add an application test.

Long term, we aught to decide if what's described above was policy;
if so, perhaps we should document it?  If not, perhaps we should add
APR_HAVE_SYS_STAT_H for apr 2.0 (even for 1.4)?

Bill

Re: When to use HAVE_XXX_H or APR_HAVE_XXX_H

[Jeff Trawick <tr...@gmail.com>]

On Thu, Sep 17, 2009 at 3:35 AM, Rainer Jung <ra...@kippdata.de>wrote:

In the case of sys/stat.h this leads to the situation, that code uses
> APR_HAVE_SYS_STAT_H although it seems it is never defined. Even some
> files in apr itself use this define. Other files in apr use
> HAVE_SYS_STAT_H.
>

APR bug

>
> Is there some policy, when to use APR_HAVE_* defines for testing the
> includes and when to use the HAVE_* type defines?
>

I wouldn't call it a policy but here goes:  For an APR application, if all
supported levels of APR provide a corresponding APR_HAVE_foo_H then use that
symbol, else provide your own auto-detection which sets HAVE_foo_H and use
that.