apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Max Bowsher" <m...@ukf.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:26:02 GMT
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?)


View raw message