[PATCH] auto-generate apr.dsp and libapr.dsp files
Here's the first version of the auto-generate DSP files patch that might
actually work. When diffed against the old DSP files the differences
all seem minor enough that this should work, although I have no real
proof since I don't have VC6 for testing.
This uses a similar approach to the DSP generators in Subversion,
although it's considerably simpler that what is required there since
APRs source tree isn't nearly as complex. This doesn't generate any of
the minor DSP files, it seemed more useful to generate the build for the
main APR libraries, since that's what is likely to change often.
The only difference between the new DSP files and the existing DSP files
is that the source files are no longer within subgroups for each
subdirectory. Doing so is irritating in EZT, so assuming that VC6 can
deal with a single group that holds all the source files I'd prefer to
leave it like this.
I haven't tried to extend this functionality to APR-Util yet, although
it shouldn't be overly complex to do so once we know that this works for
APR.
Please let me know of the results of any tests, I'm rather curious if
this stuff works.
-garrett
Auto generate Visual C++ dsp files for building apr-1.lib and libapr-1.dll.
* build.conf
(win32-fixups): lists of files that need to be added or removed from parts
of the windows build system.
* build/gen-build.py
(main): instead of doing the makefile generation inline call out to new
do_make_platforms and do_windows functions.
(do_make_platforms): holds the logic that used to be in main.
(do_windows): logic for building the windows .dsp files for apr-1.lib and
libapr-1.dll.
(win32ify_paths): new helper function.
* build/ezt.py: Greg Stein's EZT package for simple templating.
* build/dsp.ezt: new, a template for generating apr.dsp and libapr.dsp.
Index: build.conf
===
--- build.conf (revision 106112)
+++ build.conf (working copy)
@@ -24,3 +24,31 @@
# we have a recursive makefile for the test files (for now)
# test/*.c
+
+# some stuff that needs to explicitly be added or removed from the list of
+# files built on win32. this is on top of what can be deduced by the rule
+# of using whatever is in the win32 subdir unless there isn't one, in which
+# case we just fall back to whatever's in the unix subdir.
+[win32-fixups]
+add-files =
+ file_io/unix/copy.c
+ file_io/unix/fileacc.c
+ file_io/unix/filepath_util.c
+ file_io/unix/fullrw.c
+ file_io/unix/mktemp.c
+ file_io/unix/tempdir.c
+ misc/unix/errorcodes.c
+ misc/unix/getopt.c
+ misc/unix/otherchild.c
+ misc/unix/version.c
+ mmap/unix/common.c
+ network_io/unix/inet_ntop.c
+ network_io/unix/inet_pton.c
+ network_io/unix/sockaddr.c
+
+remove-files =
+ support/unix/waitio.c
+ misc/win32/apr_app.c
+
+remove-headers =
+ include/apr.h
Index: build/ezt.py
===
--- build/ezt.py(revision 0)
+++ build/ezt.py(revision 0)
@@ -0,0 +1,585 @@
+#!/usr/bin/env python
+ezt.py -- easy templating
+
+ezt templates are very similar to standard HTML files. But additionally
+they contain directives sprinkled in between. With these directives
+it is possible to generate the dynamic content from the ezt templates.
+
+These directives are enclosed in square brackets. If you are a
+C-programmer, you might be familar with the #ifdef directives of the
+C preprocessor 'cpp'. ezt provides a similar concept for HTML. Additionally
+EZT has a 'for' directive, which allows to iterate (repeat) certain
+subsections of the template according to sequence of data items
+provided by the application.
+
+The HTML rendering is performed by the method generate() of the Template
+class. Building template instances can either be done using external
+EZT files (convention: use the suffix .ezt for such files):
+
+ template = Template(../templates/log.ezt)
+
+or by calling the parse() method of a template instance directly with
+a EZT template string:
+
+ template = Template()
+ template.parse('''htmlhead
+... title[title_string]/title/head
+... bodyh1[title_string]/h1
+...[for a_sequence] p[a_sequence]/p
+...[end] hr
+...The [person] is [if-any state]in[else]out[end].
+... /body
+... /html
+... ''')
+
+The application should build a dictionary 'data' and pass it together
+with the output fileobject to the templates generate method:
+
+ data = {'title_string' : A Dummy Page,
+... 'a_sequence' : ['list item 1', 'list item 2', 'another
element'],
+... 'person': doctor,
+... 'state' : None }
+ import sys
+ template.generate(sys.stdout, data)
+htmlhead
+titleA Dummy Page/title/head
+bodyh1A Dummy Page/h1
+ plist item 1/p
+ plist item 2/p
+ panother element/p
+ hr
+The doctor is out.
+/body
+/html
+
+Template syntax error reporting
Re: [PATCH] auto-generate apr.dsp and libapr.dsp files
Garrett Rooney wrote:
+def win32ify_paths(paths):
+ rpaths = []
+ for p in paths:
+segs = re.split('/', p)
+rp = '.\\' + string.join(segs, '\\')
+rpaths.append(rp)
+
+ return rpaths
Hmmm
def win32ify_paths(paths):
return map(lambda x: '.\\'+string.replace(x, '/', '\\'), paths)
Howzat? :-)
+
+
+def do_windows(parser):
+ subdirs = []
+
+ for subdir in string.split(parser.get('options', 'platform_dirs')):
+path = '%s/%s' % (subdir, 'win32')
Why not
path = os.path.join(subdir, 'win32')?
You do the win32ification later on anyway.
On the whole, it looks good. I'll give it a spin tomorrow. We can add
the file groups later on (they're not necessary, but they do make it
easier for the user).
Regarding the lesser dsps: I fully expect them to be generated later
on, because we'll want to be able to create VS.NET .vcproj files, too.
-- Brane
Re: [PATCH] auto-generate apr.dsp and libapr.dsp files
Branko ibej wrote:
Garrett Rooney wrote:
+def win32ify_paths(paths):
+ rpaths = []
+ for p in paths:
+segs = re.split('/', p)
+rp = '.\\' + string.join(segs, '\\')
+rpaths.append(rp)
+
+ return rpaths
Hmmm
def win32ify_paths(paths):
return map(lambda x: '.\\'+string.replace(x, '/', '\\'), paths)
Howzat? :-)
Hey, I never said I was good at python ;-)
+
+
+def do_windows(parser):
+ subdirs = []
+
+ for subdir in string.split(parser.get('options', 'platform_dirs')):
+path = '%s/%s' % (subdir, 'win32')
Why not
path = os.path.join(subdir, 'win32')?
You do the win32ification later on anyway.
Yeah, that would make more sense...
On the whole, it looks good. I'll give it a spin tomorrow. We can add
the file groups later on (they're not necessary, but they do make it
easier for the user).
Cool.
Regarding the lesser dsps: I fully expect them to be generated later
on, because we'll want to be able to create VS.NET .vcproj files, too.
Oh, I agree, they should be generated as well, but one step at a time.
I figured it was easier to build things out for the libs first, since
that's all that's really needed for it to start to be useful, then move
on to the rest of the build.
-garrett
Re: [PATCH] fix apr_xlate_conv_buffer and testxlate
Here's what I propose to fix this, anything I'm missing?
Index: include/apr_xlate.h
===
--- include/apr_xlate.h (revision 106171)
+++ include/apr_xlate.h (working copy)
@@ -102,8 +102,15 @@
* @param outbytes_left Input: the size of the output buffer
* Output: the amount of the output buffer not yet used
* @remark
- * Return APR_ENOTIMPL if charset transcoding is not available
- * in this instance of apr-util (i.e., APR_HAS_XLATE is undefined).
+ * Returns APR_ENOTIMPL if charset transcoding is not available
+ * in this instance of apr-util (i.e., APR_HAS_XLATE is undefined).
+ * Returns APR_INCOMPLETE if the input buffer ends in an incomplete
+ * multi-byte character.
+ *
+ * To correctly terminate the output buffer for some multi-byte
+ * character set encodings, a final call must be made to this function
+ * after the complete input string has been converted, passing
+ * the inbuf and inbytes_left parameters as NULL.
*/
APU_DECLARE(apr_status_t) apr_xlate_conv_buffer(apr_xlate_t *convset,
const char *inbuf,
Index: xlate/xlate.c
===
--- xlate/xlate.c (revision 106171)
+++ xlate/xlate.c (working copy)
@@ -385,7 +385,7 @@
else
#endif
-{
+if (inbuf) {
int to_convert = min(*inbytes_left, *outbytes_left);
int converted = to_convert;
char *table = convset-sbcs_table;
Index: test/testxlate.c
===
--- test/testxlate.c(revision 106171)
+++ test/testxlate.c(working copy)
@@ -53,6 +53,11 @@
inbytes_left,
buf,
outbytes_left);
+if (status == APR_SUCCESS) {
+status = apr_xlate_conv_buffer(convset, NULL, NULL,
+ buf + sizeof(buf) - outbytes_left - 1,
+ outbytes_left);
+}
buf[sizeof(buf) - outbytes_left - 1] = '\0';
retcode |= check_status(status, apr_xlate_conv_buffer);
if ((!status || APR_STATUS_IS_INCOMPLETE(status))
Re: [PATCH] fix apr_xlate_conv_buffer and testxlate
Joe Orton wrote: Here's what I propose to fix this, anything I'm missing? Thats nearly the same as the patch I made in my wc. (Well, I didn't fix the documentation in apr_xlate.h.) My code does the same as yours, so it should be ok. In my opinion, what's missing is the test, that apr_xlate_conv_buffer behaves in the same way by using apr_iconv. Bye Uwe -- Uwe Zeisberger http://www.google.com/search?q=2004+in+roman+numerals signature.asc Description: Digital signature
Re: [PATCH] fix apr_xlate_conv_buffer and testxlate
On Mon, 22 Nov 2004 11:34:10 +0100, Uwe Zeisberger [EMAIL PROTECTED] wrote: Joe Orton wrote: Here's what I propose to fix this, anything I'm missing? it makes sense to me
Re: [PATCH] fix apr_xlate_conv_buffer and testxlate
On Mon, Nov 22, 2004 at 06:26:33AM -0500, Jeff Trawick wrote: On Mon, 22 Nov 2004 11:34:10 +0100, Uwe Zeisberger [EMAIL PROTECTED] wrote: Joe Orton wrote: Here's what I propose to fix this, anything I'm missing? it makes sense to me OK, thanks, I've committed that fix to the trunk. Uwe, thanks for tracking this down. joe
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
William A. Rowe, Jr. wrote: At 08:23 AM 11/20/2004, Jim Jagielski wrote: On Nov 20, 2004, at 12:03 AM, Justin Erenkrantz wrote: So, my opinion is that we let Allen branch apr off now and let him go at it at a measured pace, but we shouldn't intend to hold httpd 2.2 for that. -- justin +1. Of course, I am assuming that his 64bit fixes will likely break binary compatibility. It does - that's the rub. And, for 2.2, this was always the plan. And that's precisely the reason we should attack the 64 bit problem for 2.2. This will give the 2.2 series a much longer life than if we push off the 64 bit work to 2.4. Bill
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
At 10:08 AM 11/22/2004, Bill Stoddard wrote: William A. Rowe, Jr. wrote: At 08:23 AM 11/20/2004, Jim Jagielski wrote: On Nov 20, 2004, at 12:03 AM, Justin Erenkrantz wrote: So, my opinion is that we let Allen branch apr off now and let him go at it at a measured pace, but we shouldn't intend to hold httpd 2.2 for that. -- justin +1. Of course, I am assuming that his 64bit fixes will likely break binary compatibility. It does - that's the rub. And, for 2.2, this was always the plan. And that's precisely the reason we should attack the 64 bit problem for 2.2. This will give the 2.2 series a much longer life than if we push off the 64 bit work to 2.4. +1 - well said. By the way, Allen was out for the week of AC but returns this week, perhaps he can jump back into this conversation. Yes - I understand that this means 1.x will never be used by httpd. Version numbers are cheap. The APR project should become used to this, if they are active, and httpd moves at it's normal pace, it would be easy to go through APR 2.x, 3.x, and land somewhere in version 4.x by the time httpd 2.4 or 3.0 walks out the door. Bill
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN
Bill Stoddard wrote: William A. Rowe, Jr. wrote: At 08:23 AM 11/20/2004, Jim Jagielski wrote: On Nov 20, 2004, at 12:03 AM, Justin Erenkrantz wrote: So, my opinion is that we let Allen branch apr off now and let him go at it at a measured pace, but we shouldn't intend to hold httpd 2.2 for that. -- justin +1. Of course, I am assuming that his 64bit fixes will likely break binary compatibility. It does - that's the rub. And, for 2.2, this was always the plan. And that's precisely the reason we should attack the 64 bit problem for 2.2. This will give the 2.2 series a much longer life than if we push off the 64 bit work to 2.4. I agree... Otherwise, we won't see many people move to 2.2 since 3rd party modules won't be available for it, since module developers will know that within a short amount of time, they'll need to redo their modules for the 64bit fixes. -- === Jim Jagielski [|] [EMAIL PROTECTED] [|] http://www.jaguNET.com/ There 10 types of people: those who read binary and everyone else.
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
At 11:08 AM 11/22/2004, Cliff Woolley wrote: On Mon, 22 Nov 2004, William A. Rowe, Jr. wrote: Yes - I understand that this means 1.x will never be used by httpd. Version numbers are cheap. The APR project should become used to this, if they are active, and httpd moves at it's normal pace, it would be easy to go through APR 2.x, 3.x, and land somewhere in version 4.x by the time httpd 2.4 or 3.0 walks out the door. Do you understand how ridiculous that sounds? How so? Let's imagine the release -after- 2.2 takes another 12-18 months. Perhaps the event mpm gets plugged in, and it takes three months, alone, just to find all the gotchas of thread-jumping. In the meantime, apr is adopted by other projects. These coders offer up some solid functionality for their own applications, and the apr team agrees. Yes, I realize most of the time new functionality can be a minor bump of apr. Yes, I realize apr has not been all that active in the past 12 months. All I'm arguing is that apr shouldn't be addicted to some 1:1 correspondence of httpd and apr bumps. Bill
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN migration complete
On Mon, 22 Nov 2004, William A. Rowe, Jr. wrote: Yes - I understand that this means 1.x will never be used by httpd. Version numbers are cheap. The APR project should become used to this, if they are active, and httpd moves at it's normal pace, it would be easy to go through APR 2.x, 3.x, and land somewhere in version 4.x by the time httpd 2.4 or 3.0 walks out the door. Do you understand how ridiculous that sounds?
Re: APR 1.0.1 and 0.9.5 posted for review
Justin Erenkrantz wrote: Can we please get some feedback on the following releases: http://www.apache.org/~jerenkrantz/0.9.5/ (The directory actually contains 0.9.5 and 1.0.1.) 1.0.1 builds successfully as an RPM under RHEL3. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN
--On Monday, November 22, 2004 11:27 AM -0500 Jim Jagielski [EMAIL PROTECTED] wrote: I agree... Otherwise, we won't see many people move to 2.2 since 3rd party modules won't be available for it, since module developers will know that within a short amount of time, they'll need to redo their modules for the 64bit fixes. I expect that as it stands right now most 2.0 modules will compile for 2.2 with very minor (if any) changes. If we 'fix' 64-bit issues now, then that means that their modules are going to undergo massive changes. That *will* affect the 2.2 uptake rate because our third parties will take a lot of time to get their modules 64-bit clean (if they do at all). I still think this needs to be punted to 2.4. It's just *way* too big. We'll also have to fix up all of httpd to be 64-bit clean. And, that's going to push 2.2 out even further. This is something we should take our time on - not try to rush out the door and then have to go back and clean up because we rushed 2.2 (and APR 2.0) out the door. No thanks. -- justin
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN
At 12:17 PM 11/22/2004, Justin Erenkrantz wrote: I expect that as it stands right now most 2.0 modules will compile for 2.2 with very minor (if any) changes. If we 'fix' 64-bit issues now, then that means that their modules are going to undergo massive changes. This I will attest to; porting to 2.2 for mod_aspdotnet, I encountered; - lost APR_BRIGADE_FOREACH - changed apr_pool_get_parent // apr_pool_parent_get and of course; link to libapr-1 / libaprutil-1. other than that, it was very clean. That *will* affect the 2.2 uptake rate because our third parties will take a lot of time to get their modules 64-bit clean (if they do at all). WHO CARES?!? That's on them. They can release bug fixes after bug fixes, or extend their list of tested/supported platforms as they get around to it. It's their problem. As it stands, WE will be in THEIR WAY with incorrect code in apr and httpd. At that point - they cannot address the problems until we release the next version minor (2.4 or 3.0). How unfair is that? I still think this needs to be punted to 2.4. It's just *way* too big. Way too big for you to handle? Ok. Not asking you to develop, test or even review. We'll also have to fix up all of httpd to be 64-bit clean. Not hard. And, that's going to push 2.2 out even further. It's pointless arguing this aspect. Are we done with 2.2? If you want to vote on 2.2 - then vote on 2.2 - don't get in the way of other developers' progress with hand waving. That, I think, is the biggest lesson I took out of the httpd luncheons. This is something we should take our time on - not try to rush out the door and then have to go back and clean up because we rushed 2.2 (and APR 2.0) out the door. No thanks. -- justin I could say the same about... ...nevermind. The lesson we learned, in a nutshell; When httpd 2.1-dev is mostly satisfactory, and we have an alpha that the community decides is ready to take to 2.2 - we fork. That fork gets stabilization improvements until it's beta, and finally GA quality. That GA release is titled 2.2.0. In the meantime, head becomes 2.3-dev. Once again, nobody is standing in the way of code fixes. They can be percolated down to the 2.2 branch (before or after 2.2.0 is blessed), and even all the way to the 2.0 branch. That requires more review, which it should so 'stable' branches don't destabilize.
Re: 2.2 roadmap with respect to APR was Re: [NOTICE] CVS to SVN
--On Monday, November 22, 2004 1:08 PM -0600 William A. Rowe, Jr. [EMAIL PROTECTED] wrote: That *will* affect the 2.2 uptake rate because our third parties will take a lot of time to get their modules 64-bit clean (if they do at all). WHO CARES?!? That's on them. They can release bug fixes after bug fixes, or extend their list of tested/supported platforms as they get around to it. It's their problem. No, but as we learned from 2.0, third-party modules have a direct impact on the uptake rate. So, making it harder for third-parties to port would make it much harder to see 2.2 in deployment. As it stands, WE will be in THEIR WAY with incorrect code in apr and httpd. At that point - they cannot address the problems until we release the next version minor (2.4 or 3.0). How unfair is that? 2.0 has the same problem and I've yet to see any real complaints. I don't want to see 2.2 be the 'end-all-be-all' - I want 2.2 to be a usable and incremental improvement over 2.0. I still think this needs to be punted to 2.4. It's just *way* too big. Way too big for you to handle? Ok. Not asking you to develop, test or even review. Way too big for third-parties to handle easily. We'll also have to fix up all of httpd to be 64-bit clean. Not hard. So say you without any code to back that statement up. We don't even know the extent of the changes at this point. It's pointless arguing this aspect. Are we done with 2.2? If you want to vote on 2.2 - then vote on 2.2 - don't get in the way of other developers' progress with hand waving. That, I think, is the biggest lesson I took out of the httpd luncheons. No offense, but I see you holding up the development by saying that 2.2 must wait for changes that aren't even written nor likely to be quickly accomplished and tested. -- justin
Re: svn commit: r106214 - /apr/apr/trunk/CHANGES /apr/apr/trunk/configure.in /apr/apr/trunk/include/apr.h.in /apr/apr/trunk/misc/unix/rand.c
On Mon, Nov 22, 2004 at 08:14:26PM -, Paul Querna wrote: Author: pquerna Date: Mon Nov 22 12:14:25 2004 New Revision: 106214 Modified: apr/apr/trunk/CHANGES apr/apr/trunk/configure.in apr/apr/trunk/include/apr.h.in apr/apr/trunk/misc/unix/rand.c Log: Use uuid_generate() and uuid_create() for the apr_os_uuid_get() interface on platforms that support them. Tested On: Linux 2.6 (libuuid) and FreeBSD 5.2.1 (libc has uuid_create) Neat... that's a good way fix for the why does the uuid code hang forever problem (waiting for /dev/random). +memcpy( (void*)uuid_data, (const void *)g, sizeof( uuid_t ) ); + Please watch the code style, Paul! joe
Re: svn commit: r106214 - /apr/apr/trunk/CHANGES /apr/apr/trunk/configure.in /apr/apr/trunk/include/apr.h.in /apr/apr/trunk/misc/unix/rand.c
Joe Orton wrote: On Mon, Nov 22, 2004 at 08:14:26PM -, Paul Querna wrote: +memcpy( (void*)uuid_data, (const void *)g, sizeof( uuid_t ) ); Please watch the code style, Paul! Not sure exactly what Joe is referring to, but note that it should never be necessary to cast anything to const void * - the whole point of accepting const void * is that it means accept pointers to anything, writable or not. You don't need to cast to void * either unless the value you're casting was a pointer to const and you're casting away the const. Casts are bad! - Julian
Re: svn commit: r106214 - /apr/apr/trunk/CHANGES /apr/apr/trunk/configure.in /apr/apr/trunk/include/apr.h.in /apr/apr/trunk/misc/unix/rand.c
On Mon, 22 Nov 2004, Julian Foad wrote: Joe Orton wrote: On Mon, Nov 22, 2004 at 08:14:26PM -, Paul Querna wrote: +memcpy( (void*)uuid_data, (const void *)g, sizeof( uuid_t ) ); Please watch the code style, Paul! Not sure exactly what Joe is referring to, but note that it should never be necessary to cast anything to const void * - the whole point of accepting const void * is that it means accept pointers to anything, writable or not. You don't need to cast to void * either unless the value you're casting was a pointer to const and you're casting away the const. Yes, the casts are unnecessary. The other style problem to which Joe was referring is the whitespace. By Apache style, it should read: memcpy(uuid_data, g, sizeof(uuid_t)); --Cliff
Re: svn commit: r106214 - /apr/apr/trunk/CHANGES /apr/apr/trunk/configure.in /apr/apr/trunk/include/apr.h.in /apr/apr/trunk/misc/unix/rand.c
Joe Orton wrote: On Mon, Nov 22, 2004 at 08:14:26PM -, Paul Querna wrote: Author: pquerna Date: Mon Nov 22 12:14:25 2004 New Revision: 106214 Modified: apr/apr/trunk/CHANGES apr/apr/trunk/configure.in apr/apr/trunk/include/apr.h.in apr/apr/trunk/misc/unix/rand.c Log: Use uuid_generate() and uuid_create() for the apr_os_uuid_get() interface on platforms that support them. Tested On: Linux 2.6 (libuuid) and FreeBSD 5.2.1 (libc has uuid_create) Neat... that's a good way fix for the why does the uuid code hang forever problem (waiting for /dev/random). Thanks. I noticed the subversion people talking about it today, and I thought that apr_os_uuid_get() already used the native interfaces on FreeBSD and Linux, but I was disappointed to find it didn't. +memcpy( (void*)uuid_data, (const void *)g, sizeof( uuid_t ) ); + Please watch the code style, Paul! Fixed. Thanks for keeping me honest. -Paul
