Steve Hay wrote on 2013-07-30: > It's actually only the path to mod_perl.so that I need to add to the > PATH, which I'd determined previously was due to the new dependency (now > in ModPerl/Const/Const.dll) on mod_perl.so for the perl_module symbol. > > I'll look at that again, or else just work around it for now by adding > to the PATH in the top-level Makefile.PL's MY::test(). >
For the record, I have now committed that "workaround" in rev. 1509781 after deciding that it's fine, not just a nasty hack. The commit message hopefully describes my reasoning adequately: "Add the path to mod_perl.so to the PATH when running the test suite on Windows Httpd.exe is able to find mod_perl.so because the test httpd.conf contains a LoadModule line with the fully qualified path to mod_perl.so in it. However, before httpd.exe is started the test framework must create that httpd.conf file. In the case of mod_perl it uses perl.exe and goes into Apache/TestConfigPerl.pm's run_apache_test_configure(), which runs APACHE_TEST_CONFIGURE() in various modules in t/response/TestApache (e.g. subprocess.pm). Those modules all use Apache2::Const, but Apache2/Const/Const.dll and ModPerl/Const/Const.dll now depend on mod_perl.so for the 'perl_module' symbol. Therefore, perl.exe must be able to find mod_perl.so when running the tests, and this is the easiest way to achieve that. There is no problem with Apache2::Const and ModPerl::Const depending on mod_perl.so because they are normally only used within a mod_perl application, which will (obviously) have mod_perl.so loaded already. (It is only the APR::* modules which we are at pains (elsewhere) to avoid having a dependency on mod_perl.so because they are of use outside of mod_perl applications.)" --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@perl.apache.org For additional commands, e-mail: dev-h...@perl.apache.org
