It was discussed earlier about renaming the aprext static library (used to build APR::* outside of mod_perl.so) to modperl_aprext, and then install it in the Apache2 lib/ directory, so as to be available to 3rd party modules. The following diff does that. I've created an aprext_libs sub within Apache::Build to return the name of the library (in analogy with the apache_libs and modperl_libs subs); this is more as a placeholder for the future, when subclasses containing platform-specific code for Win32 are made.
+1
I'm not 100% sure about the naming though. If this is for third party modules which need that library w/o mod_perl, then won't it be confusing if they have to use something that includes mod_perl in the name? Won't they start asking questions, do I use mod_perl?
Granted, you can't have APR w/o building mod_perl, but it's possible to have APR w/o mod_perl if someone creates binary packages which provide only the files needed for APR, in which case modperl_ might be not the best name. May be we need to come up with aprperl_ or perlapr_ or perl_apr_ (or else) prefix for methods and for filenames which don't need modperl?
And I kept in mind to use File::Spec->catdir within a MY ...
:)
-- __________________________________________________________________ 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]
