Fred Moyer <f...@redhotpenguin.com>: > > What else? Time for 2.4 httpd?
Debian is also moving to Apache 2.4 and we've been working on getting mod_perl2 to cope. We're currently using the httpd24 branch as a base (thanks for your work, Jan!), merged with the 2.0.8 release. We found a few issues that I intend to post as separate patches / reports soonish, but we've generally got it working now. On Fri, Apr 19, 2013 at 02:22:25AM -0400, Jan Kaluza wrote: > I think we have to create new mod_perl row for httpd24 or change the build > process. FWIW I'd be willing to help here too (as time permits), but I'm not really familiar with the build process. Opinions and advice from more experienced mod_perl developers would be welcome. Selectively quoting the options you listed: > a) have two branches - trunk and httpd24 (analogy to httpd-trunk and > httpd-2.4). I think this is clearly not optimal in the long term, but if it is how things are going to be, maybe SVN merges would help to avoid committing everything twice. At the moment httpd24 is lagging behind trunk. There seems to be a need for making sure they stay synchronised. Would there be separate releases for 2.0.9 and 2.0.9-httpd24 ? > b) have just trunk for both httpd24 and httpd22 code [...] > 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. As I understand it, this has the drawback that a developer changing an xs map needs to have access to both 2.2 and 2.4 to run 'xs_generate' for both. But I guess they'd have to have that anyway for testing. How was this handled for the Apache 2.0 -> 2.2 changes? Are there just more API differences in 2.4? > 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. For the purposes of Debian alone, I think c) would be adequate (we probably could and should make sure xs_generate works there), but I agree b) is generally better for end users. -- Niko Tyni nt...@debian.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org For additional commands, e-mail: dev-h...@perl.apache.org
