----- Original Message ----- > We're good to go for 2.0.9-dev commits. > > I'm going to restore being able to run the tests (instead of skipping) as > root user. I can't remember what the issue was before, but it looks like > most cpan testers are root user. > > What else? Time for 2.4 httpd? >
I think we have to create new mod_perl row for httpd24 or change the build process. C code in httpd24 branch should compile (thanks to #ifdefs) with httpd-2.2, but there is problem with ./xs directory. One can't make any conditionals in text files located there. This makes it impossible to create single code to build against both 2.2 and 2.4. Also, we should run "make xs_generate" just once on single machine where it's known to work, because it will fail for some people depending on files in their /usr/include/. I think there are 2+1 solutions: a) have two branches - trunk and httpd24 (analogy to httpd-trunk and httpd-2.4). We would then commit common things to both branches, httpd-2.4 things to httpd24 branch. This makes it possible for users to test mod_perl from svn, because xs files are generated in both branches. It's also somehow easier for us at the beginning, because no more work is needed to start this way of development. b) have just trunk for both httpd24 and httpd22 code. I think we would have to change the build process to detect if it's building against httpd24 and in this case, new ./xs24 directory should be used (maybe it's possible to use just different ./xs/maps24 and ./xs/tables24... I would have to check what's exactly generated by xs_generate). In this case, it's harder for us to start the development this way, but we then share 90% of the code between both versions in trunk, we can release just single tarball and so on. I don't know XS well, but if you think it's easy enough to change build to use different xs directory (or its subset) for 2.4 and different for 2.2, then I think this is way to go. This would need some extra work in httpd24 branch to be really sure it does not break compatibility with httpd22, but I'm OK with doing that if we decide to go this way and someone will improve the build process to make it possible. c) merge just httpd24 .c/.h changes to trunk and let the users/devs to run make xs_generate themselves and try to fix the /usr/include/ parser to be more reliable. I think this is not the right solution. It makes more work for us trying to fix C parser and also more work for users trying to compile mod_perl. xs_generate is not reliable and can fails randomly on some /usr/include files which makes the compilation impossible without changing mod_perl code. Regards, Jan Kaluza --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org For additional commands, e-mail: dev-h...@perl.apache.org
