Apr 18, 2013, 11:22 PM
Post #2 of 2
(1237 views)
Permalink
----- 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-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org