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

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

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
>>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 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.

Bill

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

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

At 05:20 PM 2/7/2005, Justin Erenkrantz wrote:

>autoconf uses apr_version.h to determine what version of APR we are using at build-time.

IIUC, autoconf is doing some complex grep extraction of the
tokens, no?

IIUC, changing to a c-preprocessor only flavor will buy us
the ability to actually run this through the autoconf c code
processing even -before- we've generated apr.h, no?

>So, I'd recommend reverting and adding the required MSVC-ism.  -- justin

The alternative I see, is to add an external -DAPR_VERSION_ONLY
which would toggle -off- the apr.h include, cplusplus cruft,
and our apr_version() structures and function declaration.

Would that be more legible?

Bill 

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

[Justin Erenkrantz <ju...@erenkrantz.com>]

--On Monday, February 7, 2005 5:06 PM -0600 "William A. Rowe, Jr." 
<wr...@rowe-clan.net> wrote:

> 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.

I think placing the MSVC-isms in apr_version.h would be far better than 
creating a file that makes no sense and is unnecessary.

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

Absolutely.  ap_release.h is a bad name.  It should be httpd_version.h.  I 
don't know the implications of renaming it though, so I haven't brought it 
up yet.

But, *_release.h or *_revision.h are bad names.  *_version.h is Right(TM).

> 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.

autoconf uses apr_version.h to determine what version of APR we are using 
at build-time.

So, I'd recommend reverting and adding the required MSVC-ism.  -- justin

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

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

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

Given the very aptly named apr_version.h already exists, a little bit of 
preprocessor wrapping seems much nicer than scattering the version 
functionality across two files.

...
> 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.

Indeed, but what if anyone wanted the version before configure has been run? 
They might be doing just that - especially since win32ver.awk was setting 
that example!
(No, I don't know of anyone doing this - but if it is non-painful to 
maintain that compatibilty - why not maintain it?)

Max.