You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@apr.apache.org by wr...@apache.org on 2005/02/07 23:44:12 UTC
svn commit: r151766 - apr/apr/trunk/include/apr_general.h
apr/apr/trunk/include/apr_release.h apr/apr/trunk/include/apr_version.h
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.
Added:
apr/apr/trunk/include/apr_release.h (with props)
Modified:
apr/apr/trunk/include/apr_general.h
apr/apr/trunk/include/apr_version.h
Modified: apr/apr/trunk/include/apr_general.h
URL: http://svn.apache.org/viewcvs/apr/apr/trunk/include/apr_general.h?view=diff&r1=151765&r2=151766
==============================================================================
--- apr/apr/trunk/include/apr_general.h (original)
+++ apr/apr/trunk/include/apr_general.h Mon Feb 7 14:44:09 2005
@@ -144,10 +144,13 @@
* String and memory functions
*/
+/* APR_STRINGIFY is defined here, and also in apr_revision.h, so wrap it */
+#ifndef APR_STRINGIFY
/** Properly quote a value as a string in the C preprocessor */
#define APR_STRINGIFY(n) APR_STRINGIFY_HELPER(n)
/** Helper macro for APR_STRINGIFY */
#define APR_STRINGIFY_HELPER(n) #n
+#endif
#if (!APR_HAVE_MEMMOVE)
#define memmove(a,b,c) bcopy(b,a,c)
Added: apr/apr/trunk/include/apr_release.h
URL: http://svn.apache.org/viewcvs/apr/apr/trunk/include/apr_release.h?view=auto&rev=151766
==============================================================================
--- apr/apr/trunk/include/apr_release.h (added)
+++ apr/apr/trunk/include/apr_release.h Mon Feb 7 14:44:09 2005
@@ -0,0 +1,93 @@
+/* Copyright 2000-2005 The Apache Software Foundation or its licensors, as
+ * applicable.
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+#ifndef APR_RELEASE_H
+#define APR_RELEASE_H
+
+/**
+ * @file apr_release.h
+ * @brief APR Versioning Constants
+ *
+ * APR's Versioning Constants
+ *
+ * This file was introduced to support C Preprocessing without the
+ * heavyweight C API or apr.h prerequisite, and can only be expected
+ * to exist in 1.2, 2.x and later versions of APR.
+ *
+ * Do NOT directly include this file when targeting APR 0.x or 1.x,
+ * include apr_version.h instead.
+ */
+
+/* The numeric compile-time version constants. These constants are the
+ * authoritative version numbers for APR.
+ */
+
+/** major version
+ * Major API changes that could cause compatibility problems for older
+ * programs such as structure size changes. No binary compatibility is
+ * possible across a change in the major version.
+ */
+#define APR_MAJOR_VERSION 1
+
+/** minor version
+ * Minor API changes that do not cause binary compatibility problems.
+ * Reset to 0 when upgrading APR_MAJOR_VERSION
+ */
+#define APR_MINOR_VERSION 2
+
+/** patch level
+ * The Patch Level never includes API changes, simply bug fixes.
+ * Reset to 0 when upgrading APR_MINOR_VERSION
+ */
+#define APR_PATCH_VERSION 0
+
+/**
+ * The symbol APR_IS_DEV_VERSION is only defined for internal,
+ * "development" copies of APR. It is undefined for released versions
+ * of APR.
+ */
+#define APR_IS_DEV_VERSION
+
+
+#if defined(APR_IS_DEV_VERSION) || defined(DOXYGEN)
+/** Internal: string form of the "is dev" flag */
+#define APR_IS_DEV_STRING "-dev"
+#else
+#define APR_IS_DEV_STRING ""
+#endif
+
+/* APR_STRINGIFY is defined here, and also in apr_general.h, so wrap it */
+#ifndef APR_STRINGIFY
+/** Properly quote a value as a string in the C preprocessor */
+#define APR_STRINGIFY(n) APR_STRINGIFY_HELPER(n)
+/** Helper macro for APR_STRINGIFY */
+#define APR_STRINGIFY_HELPER(n) #n
+#endif
+
+/** The formatted string of APR's version */
+#define APR_VERSION_STRING \
+ APR_STRINGIFY(APR_MAJOR_VERSION) "." \
+ APR_STRINGIFY(APR_MINOR_VERSION) "." \
+ APR_STRINGIFY(APR_PATCH_VERSION) \
+ APR_IS_DEV_STRING
+
+/** An alternative formatted string of APR's version */
+/* macro for Win32 .rc files using numeric csv representation */
+#define APR_VERSION_STRING_CSV APR_MAJOR_VERSION ##, \
+ ##APR_MINOR_VERSION ##, \
+ ##APR_PATCH_VERSION
+
+#endif /* ndef APR_RELEASE_H */
\ No newline at end of file
Propchange: apr/apr/trunk/include/apr_release.h
------------------------------------------------------------------------------
svn:eol-style = native
Modified: apr/apr/trunk/include/apr_version.h
URL: http://svn.apache.org/viewcvs/apr/apr/trunk/include/apr_version.h?view=diff&r1=151765&r2=151766
==============================================================================
--- apr/apr/trunk/include/apr_version.h (original)
+++ apr/apr/trunk/include/apr_version.h Mon Feb 7 14:44:09 2005
@@ -19,6 +19,8 @@
#include "apr.h"
+#include "apr_release.h"
+
#ifdef __cplusplus
extern "C" {
#endif
@@ -43,39 +45,6 @@
* http://apr.apache.org/versioning.html
*/
-/* The numeric compile-time version constants. These constants are the
- * authoritative version numbers for APR.
- */
-
-/** major version
- * Major API changes that could cause compatibility problems for older
- * programs such as structure size changes. No binary compatibility is
- * possible across a change in the major version.
- */
-#define APR_MAJOR_VERSION 1
-
-/**
- * Minor API changes that do not cause binary compatibility problems.
- * Should be reset to 0 when upgrading APR_MAJOR_VERSION
- */
-#define APR_MINOR_VERSION 2
-
-/** patch level */
-#define APR_PATCH_VERSION 0
-
-/**
- * This symbol is defined for internal, "development" copies of APR.
- * This symbol should be #undef'd for releases.
- */
-#define APR_IS_DEV_VERSION
-
-/** The formatted string of APR's version */
-#define APR_VERSION_STRING \
- APR_STRINGIFY(APR_MAJOR_VERSION) "." \
- APR_STRINGIFY(APR_MINOR_VERSION) "." \
- APR_STRINGIFY(APR_PATCH_VERSION) \
- APR_IS_DEV_STRING
-
/**
* The numeric version information is broken out into fields within this
@@ -99,13 +68,6 @@
/** Return APR's version information as a string. */
APR_DECLARE(const char *) apr_version_string(void);
-
-/** Internal: string form of the "is dev" flag */
-#ifdef APR_IS_DEV_VERSION
-#define APR_IS_DEV_STRING "-dev"
-#else
-#define APR_IS_DEV_STRING ""
-#endif
#ifdef __cplusplus
}
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
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Mon, Feb 07, 2005 at 08:01:53PM -0600, William A. Rowe, Jr. wrote:
> At 05:30 PM 2/7/2005, Justin Erenkrantz wrote:
>
> >+1. This approach is infinitely better than adding new files. -- justin
>
> If the APR_VERSION_ONLY works to exclude the C code (as
> opposed to the C preprocessor code) as I've now committed...
> I'd apply exactly the same fix on libapr-util and libapr-iconv.
>
> The advantage over RC_INVOKED (an MS-ism) is that our own
> pre-config scrips can run apr_version.h through the
> c preprocessor even before apr.h exists, by simply passing
> -DAPR_VERSION_ONLY. Nothing platform specific.
At the time we parse apr_version.h in autoconf via get-version.sh, we don't
yet have cpp available. So, it's of dubious value for Unix. I'd think it's
probably best to go with the RC_INVOKED #define so that we don't have to
define anything special in libapr.rc. But, I don't care much one way or the
other here what we call the #define... -- 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
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 05:30 PM 2/7/2005, Justin Erenkrantz wrote:
>+1. This approach is infinitely better than adding new files. -- justin
If the APR_VERSION_ONLY works to exclude the C code (as
opposed to the C preprocessor code) as I've now committed...
I'd apply exactly the same fix on libapr-util and libapr-iconv.
The advantage over RC_INVOKED (an MS-ism) is that our own
pre-config scrips can run apr_version.h through the
c preprocessor even before apr.h exists, by simply passing
-DAPR_VERSION_ONLY. Nothing platform specific.
Let me know if this works for everyone and I'll proceed.
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
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Monday, February 7, 2005 11:19 PM +0000 Max Bowsher <ma...@ukf.net>
wrote:
> To suggest an alternative:
>
> Put everything back where it was, and wrap the bits you don't want in:
>
># ifndef RC_INVOKED
> ...
># endif
>
> (Or another symbol, if my guess that you want to directly #include it
> from the resource compiler is wrong).
+1. This approach is infinitely better than adding new files. -- 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
Posted by Max Bowsher <ma...@ukf.net>.
Justin Erenkrantz 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.
>
> I really dislike the ap_release.h strategy used by httpd. 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
To suggest an alternative:
Put everything back where it was, and wrap the bits you don't want in:
#ifndef RC_INVOKED
...
#endif
(Or another symbol, if my guess that you want to directly #include it from
the resource compiler is wrong).
Max.
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
Posted by "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
Posted by 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
Posted by 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.
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
Posted by "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
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--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.
I really dislike the ap_release.h strategy used by httpd. 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
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
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--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.
I really dislike the ap_release.h strategy used by httpd. 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