On Mon, 17 May 2004, Stas Bekman wrote: [ ... ]
Randy Kobes wrote:
I'll try it for Windows and see how much is involved; if this works as expected, it should just involve changing how things are compiled, as well as the order (APR.so coming first). But one of the joys of working with Windows is that things are never as expected ;)
I've now tried it on Windows, and in particular the (patched) apr-ext tests pass. This though was manual;
Great!
I'll next try to get things built automatically. But
just for information, what was required was
- adjust xs/APR/APR/APR.def to include
modperl_interp_unselect
modperl_hash_tie
modperl_hash_tied_object
modperl_perl_gensym
modperl_error_strerror
in the list of exported symbols
We ought to automate that. I think you've missed symbols, like tracing functions, since you didn't build with tracing enabled or because the APR/Foo.o's that my patch tests don't use tracing. We should probably look at the the apache/apr DECLARE macros. Alternatively it can be a common group of files modperl_common_*.c but it'll be hard to extract those symbol names. Another approach is to split the tables/ModPerl/Functions.pm (which I think that's how .def is generated now). May be the function names should have a different prefix than /modperl_/. In which case it'll be clear that they are common ones.
- build APR first, so APR::* can link against it (the default action is to build APR::* first);
Really? Is it specific to win32? On linux with the current cvs, I can run 'make -j' which builds things in parallel and I was getting APR/*.so getting build while src/modules/perl/mod_perl.so was still not built. But I don't see problem with arranging what you did.
- adjust the Makefiles in APR::* to link to
blib/arch/Apache2/auto/APR/APR.lib
before linking to src/modules/perl/mod_perl.lib
Good.
- add
blib/arch/Apache2/auto/APR/
to the PATH, so APR.dll can be found (perhaps APR.dll
[APR.so] should be installed to $APACHE2/lib or
$APACHE2/bin, as appropriate?)
That's not good. The whole idea was not to create a library which will need to be searched by the loader. The ideas was to have a plain .so which will live under perl's lib, and loading any APR/Foo.pm will first load APR.so, and then APR/Foo.so. So yes, there is a need to change the autogenerated APR/*.pm files, but you shouldn't need to mess with PATH or anything that has to do with system-wide loader.
If we were to create a separate .so (read: win32/dll), that would be mod_perl_common.so since all these things in modperl_common.* have nothing to do with apr. But we want to avoid to impose that added enormous complexity on our users.
In any case, no source code changes were needed - I think all the above can be done within the Makefile generation.
It's fine to change the source if it's needed :)
Good work, Randy!
-- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
