Re: [Vote] httpd 2.2.22 release

2012-01-30 Thread William A. Rowe Jr.
On 1/30/2012 4:02 AM, Rainer Jung wrote:
 
 We add apu-1-confg --includes to CPPFLAGS and then use CPP and apu_version.h 
 to detect
 which version we have. That works for most gcc versions, but recent gcc 
 chokes, because
 apu_version.h includes apr_version.h, which can not be found due to our 
 setting of
 CPPFLAGS. gcc 4.6.2 based cpp then aborts parsing apu_version.h and our 
 version check fails.
 
 Adding apu-1-confg --includes *plus* apr-1-confg --includes to CPPFLAGS 
 before the version
 check fixes this.

That is a bug in apu-1-config; which must include the apr-1 path in
its reported --includes (and --libs).  An apu which isn't usable because
it doesn't resolve apr is worthless.

That's how all .pc and other include/lib resolvers are supposed to behave.

The same must be true for the linker.


Re: [Vote] httpd 2.2.22 release

2012-01-30 Thread Rainer Jung

On 30.01.2012 19:10, William A. Rowe Jr. wrote:

On 1/30/2012 4:02 AM, Rainer Jung wrote:


We add apu-1-confg --includes to CPPFLAGS and then use CPP and apu_version.h to 
detect
which version we have. That works for most gcc versions, but recent gcc chokes, 
because
apu_version.h includes apr_version.h, which can not be found due to our setting 
of
CPPFLAGS. gcc 4.6.2 based cpp then aborts parsing apu_version.h and our version 
check fails.

Adding apu-1-confg --includes *plus* apr-1-confg --includes to CPPFLAGS before 
the version
check fixes this.


That is a bug in apu-1-config; which must include the apr-1 path in
its reported --includes (and --libs).  An apu which isn't usable because
it doesn't resolve apr is worthless.


I proposed the same patch as was applied long ago for trunk earliert 
today for 2.2. That patch does not change apu-1-config behaviour.


Not sure whether I agree that apu should provide info about apr, since 
one could argue that that's what apr-1-config is for. So I cross post 
dev@apr and this part of the discussion could proceed there.



That's how all .pc and other include/lib resolvers are supposed to behave.

The same must be true for the linker.


Regards,

Rainer


Re: [Vote] httpd 2.2.22 release

2012-01-30 Thread William A. Rowe Jr.
On 1/30/2012 12:27 PM, Rainer Jung wrote:
 On 30.01.2012 19:10, William A. Rowe Jr. wrote:
 On 1/30/2012 4:02 AM, Rainer Jung wrote:

 We add apu-1-confg --includes to CPPFLAGS and then use CPP and 
 apu_version.h to detect
 which version we have. That works for most gcc versions, but recent gcc 
 chokes, because
 apu_version.h includes apr_version.h, which can not be found due to our 
 setting of
 CPPFLAGS. gcc 4.6.2 based cpp then aborts parsing apu_version.h and our 
 version check
 fails.

 Adding apu-1-confg --includes *plus* apr-1-confg --includes to CPPFLAGS 
 before the version
 check fixes this.

 That is a bug in apu-1-config; which must include the apr-1 path in
 its reported --includes (and --libs).  An apu which isn't usable because
 it doesn't resolve apr is worthless.
 
 I proposed the same patch as was applied long ago for trunk earliert today 
 for 2.2. That
 patch does not change apu-1-config behaviour.
 
 Not sure whether I agree that apu should provide info about apr, since one 
 could argue
 that that's what apr-1-config is for. So I cross post dev@apr and this part 
 of the
 discussion could proceed there.
 
 That's how all .pc and other include/lib resolvers are supposed to behave.

 The same must be true for the linker.

You might want to review man pkg-config --cflags.  Note --includes is in the
plural.

If the user can't use the apu_dbd API by simply plugging in apr-util, then
we did something wrong.