At 04:54 PM 2/7/2005, you wrote: >--On Monday, February 7, 2005 10:44 PM +0000 [EMAIL PROTECTED] wrote: > >>Author: wrowe >>Date: Mon Feb 7 14:44:09 2005 >>New Revision: 151766 >> >>URL: http://svn.apache.org/viewcvs?view=rev&rev=151766 >>Log: >> >> 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 [EMAIL PROTECTED] 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. Bill
