apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: svn commit: r151766 - apr/apr/trunk/include/apr_general.h apr/apr/trunk/include/apr_release.h apr/apr/trunk/include/apr_version.h
Date Mon, 07 Feb 2005 23:06:06 GMT
At 04:54 PM 2/7/2005, you wrote:
>--On Monday, February 7, 2005 10:44 PM +0000 wrowe@apache.org wrote:
>>Author: wrowe
>>Date: Mon Feb  7 14:44:09 2005
>>New Revision: 151766
>>URL: http://svn.apache.org/viewcvs?view=rev&rev=151766
>>  In order to remove the win32ver.awk generation of .rc files for apr,
>>  it's necessary to have a 'vanilla' c preprocessor file which doesn't
>>  have all the extra apr.h or other function declaration cruft.
>>  ap_release.h is the httpd project's convention, and it seems to fit
>>  the bill.  Provide "big red warnings" (tm) to not use this new file
>>  directly, if the user wants to retain compatibility with APR 0.x/1.x.
>I don't get it.  What exactly are you trying to do?  Why must you add a header file that
is exactly the same as what was in apr_version.h?  You also just broke the Unix build which
expects the version to be in apr_version.h.

As I indicated, we can either put a bunch of MSVC'isms within
#ifdef's to prevent apr.h and the function declarations from
being triggered, when this file is included by the win32 RC
(resource compiler), or ... use a simplified flavor with only
c preprocessor constructs.

Effectively, this will eliminate the need to run win32ver.awk,
so users won't need awk to build win32, and libapr.rc will just
include the version header file.

On your point, the vanilla/cpp header should become even quicker 
for the unix build system to grok.  No need to drag in apr.h.
In fact, you can now run the c preprocessor against a 'virgin'
distribution of apr, before apr.h is generated from apr.h.in.

I'm liking this more and more.

>I really dislike the ap_release.h strategy used by httpd.  

Do tell :)  httpd is moving twords 2.2 - something to fix?

My initial name was going to be apr_revision.h - I just took
a cue from httpd since it was easier.

It's clear we must have apr_version.h provide exactly what 
it has all this time, to avoid breaking anyone.  This is why
I carefully split these, and included the new c preprocessor
header from apr_version.h.

The point you raise is valid, a user who expects to grep the
file may get goofy results.  But they shouldn't be doing that
in the first place, should they?  That's what apr-config was
created for.

>I also don't think it makes sense for APR in any form.  Please discuss this first on dev@apr
so we can minimize breakage.  -- justin

I did, a month or two ago, no response.  Sometimes commits
get a little more attention, and this is CTR trunk.

Let's fix the build, and refine the concept.


View raw message