Stas Bekman wrote:

Randy Kobes wrote:

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.

I'm not sure that's the *only* mis-leading part, but, as you say, if it all works then it shouldn't really matter too much.


The main thing is to get mod_perl.lib installed in the first place under mp1.

- Steve



Reply via email to