On Fri, 12 Sep 2003, Stas Bekman wrote:
Steve Hay wrote:
Stas Bekman wrote:
Randy Kobes wrote:
On Fri, 12 Sep 2003, Steve Hay wrote:
I believe that mod_perl 2 now installs the mod_perl.lib somewhere to solve that kind of problem. Is there an option in the mod_perl 1 build process to thave that library installed, or could that be added to the next release?
That's a good suggestion - you're right that mod_perl 2 installs the mod_perl.lib under the Apache2/ tree, and it would make sense for mod_perl 1 to do the same, with Apache::MyConfig adjusted to reflect that. I'll look into putting together something to do that.
Does it? According to Apache::Build, it should be installed under the apache tree's lib:
Yes, in my Apache2 setup (the one that I can't get working with Perl 5.8.1...) I have mod_perl.lib in C:\Apache2\lib. I didn't change any of the installation locations.
I'd assumed that's what Randy meant, actually - Apache2/lib being under the Apache2/ tree :-)
what is mod_perl.lib? a static library? (I guess an equivalent of mod_perl.lo on unix). We don't install it on unix yet, but I think that for consistency it should go to the same place where mod_perl.so is installed to. Which is under the Apache tree.
This mod_perl.lib (on Win32) isn't a true static library, containing all the symbol definitions; from what I understand, it just contains the minimal information on symbols needed to allow the application it's being linked with to find the symbols in the dynamic library (in this case, mod_perl.so).
I put it under Apache2/lib/ because that's where the Apache2 libs (eg, apr.lib, libapr.lib, mod_dav.lib) are placed. The dynamic libraries are placed either under Apache2/modules/, if it's a module (eg, mod_dav.so), or under Apache2/bin/, such as libapr.dll.
Ah, so it's all cool. I have confused Apache2/ with perl's lib sub-directory.
Having said that, the BuildConfig.pm doesn't actually seem to refer to the location that the library has been installed into -- like mp1, it refers to the location in which it was built! I have:
'MODPERL_LIB_LOCATION' => 'C:/Temp/modperl-2.0/src/modules/perl/mod_perl.lib',
in BuildConfig.pm. Wouldn't it be better for that to be 'C:/Apache2/lib/mod_perl.lib'?
Nope, it uses this attribute as a source dir in cp from to:
$install .= <<'EOI'; # install mod_perl.lib @$(MKPATH) $(MODPERL_AP_LIBDIR) $(MODPERL_TEST_F) $(MODPERL_LIB_LOCATION) && \ $(MODPERL_CP) $(MODPERL_LIB_LOCATION) $(MODPERL_AP_LIBDIR) EOI
And as you can see it should install the static lib under $(MODPERL_AP_LIBDIR) (which is under the apache tree)
purhaps it should be fixed to have a more intuitive name then (s/MODPERL_LIB_LOCATION/MODPERL_LIB_SOURCE_LOCATION/?) or BUILD_LOCATION I'd suggest an even more intuitive: MODPERL_STATIC_LIB_BUILD_LOCATION, since it's a static lib. Purhaps adding a new var MODPERL_STATIC_LIB_LOCATION pointing to where the static lib was installed to will be useful.
Having a pointer to where the mod_perl.lib library was installed would be useful. I'm not sure calling it MODPERL_STATIC_LIB_LOCATION would be the best thing on Win32, as it's not a static library as such, but something could be come up with ...
Well, if ModPerl::MM does the right thing, a developer will not even need to know where it is located. So probably leaving it as it's now is fine. The only misleading part is that MODPERL_LIB_LOCATION points to the build dir, so it should probably be renamed to reflect that.
__________________________________________________________________ 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
