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.
