On Fri, 21 Mar 2003 15:23:42 +1100, "Stas Bekman" <[EMAIL PROTECTED]> said:
Kermit Tensmeyer wrote: [...]
'/usr/local/apache/bin/apxs';
as nears as I can tell, the last option is a hard-code hack that will fail for most sites
Sorry if I've snipped too much, but am I correct that this is the gist of
the problem? mp2's build picks the wrong /usr/local/apache/bin/apxs and this
is the root of the problem?
that's part of the problem mp2's build picks `a` apxs, but modperl
Makefile.PL explictly asks to use a specfic apache source tree to
'configure' mp2 with. I think it ought to use the apxs the resides in
that specfic source tree.
OK, so I still don't understand why it doesn't work for you. It doesn't find apxs at all? It finds the wrong apxs? What's the current problem, that makes $build->apxs(q => ...) fail?
mod_perl already supplies the mechanics to perform the functinality of
apxs, because apxs simply doesn't work on platforms like win32.
If that supplies a general solution (I'll check tonight)(i don't use
win32)
then it could be a better solution.
I had another thought. As it stands every single invocation of
$build->apxs
goes thru the process of guessing which external script to execute and
each time
parses the config variable file to extract one and only one value, but
apxs builds
out a hash of all the variables.
What if the build->apxs would extract out the four values and save
those values in the build hash, and then serve those value on subsequent calls to the
function.
hmm.. One parse of the file. One or less external invoking of perl
script.
That's not a critical issue. Sure we can make it more efficient, but this is just a build process. Rather spend time first improving other things.
That's certainly after we make it working for you. If in the process things get improved, that's cool. But first I need to understand why it doesn't work for you.
So if you remove that hardcoded path, do things start to work?
Nope..
but before I think about rewriting the apache::build module, i think this other discussion about the weakness of apache::MM should get resolved. I'll look at the M::B stuff this weekend no sense working of stuff that will be replaced soon.
replaced? Are you talking about ModPerl::MM? it won't be replaced, but moved into ModPerl::BuildMM and ModPerl::MM will be design explicitly for use with 3rd party modules.
__________________________________________________________________ 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]
