Nick *** wrote:
>> >> Why MP_AP_PREFIX and MP_APR_CONFIG cannot be used together? I guess >> >> this is valid only when MP_AP_PREFIX is pointing to an installed httpd,
>> >> because when MP_AP_PREFIX is pointing to a source tree, I can get
>> >> around this check by adding MP_AP_CONFIGURE="--with-apr=...". It's
>> >> logical to me that this check should work only when MP_AP_PREFIX is not
>> >> pointing to a source tree, because, I think, it shouldn't be possible
>> >> to build mod_perl with different apr than the one httpd was build with.
>> >> But then again, if the above is true, there should be the same check
>> >> for MP_APR_CONFIG and MP_APXS, because as I see in Apache2::Build,
>> >> MP_APR_CONFIG will take precedence over the value supplied by apxs. Is
>> >> my guess a good one?
>> >
>> >While MP_AP_PREFIX originally was used to point to the install tree, it's >> >no longer the case. MP_AP_PREFIX should only be used when building a >> >statically linked httpd/mod_perl. In which case you don't need >> >MP_APR_CONFIG, since all the needed sources live under MP_AP_PREFIX.
>> >> But if I have previously installed apr in /usr/apr,
>> and when I want to build a static MP and want both apache and MP to use /usr/apr instead of srclib/apr, I'd like to use
>> perl Makefile.PL MP_AP_PREFIX=../httpd MP_APR_CONFIG=/usr/apr/apr-config
>
>Hmm. So are you saying that if mod_perl builds against source it won't be >using the right apr?
No, now it picks and install the right stuff and there is no problem
with that. The problem is that I want to use MP_AP_PREFIX and
MP_AP(R|U)_CONFIG arguments together when building a static MP. Why do
I think it's good to have it? Well, my dev machine is a slow one and
every time I have to rebuild a static MP I have to wait a long time, because the process compiles mod_perl, apr, apr-util, pcre and httpd. But if I compile and install apr and apr-util in /usr/lib once, then I can just use perl Makefile.PL MP_USE_STATIC=1 MP_AP_PREFIX=../httpd
MP_AP(R|U)_CONFIG=/usr/lib/ap(r|u)-config, so both MP and Apache will
use these.
What are the advantages?
- You'll wait half of the time when compiling a static MP. - You can use a special port of apr and apr-util suited for your operating system, instead of the generic ones that come in srclib/ (which is the case with my Cygwin installation).
OK, I understand the advantages, Nick. But have you considered the possible disadvantages? Like users messing up with too many options available and then start reporting non-existing bugs in the best case and in the worst case giving up and moving on to something different? Things are already a way too complicated with the static build, let's not complicate those further.
In any case, once 2.0 is out and you have the cygwin fixed up, it's not like you are going to rebuild things every day, is it?
What other developers think? I'm -0.5 on this idea due to the reasons explained in the above paragraph, but if others think it's a useful change, i won't stand on the way.
>> 3. A better check whether --with-apr=/path is a file > >> Index: lib/Apache2/Build.pm >> =================================================================== >[...] >> @@ -1116,7 +1127,7 @@ >> if ($self->{MP_AP_CONFIGURE} && >> $self->{MP_AP_CONFIGURE} =~ /--with-${what_long}=(\S+)/) { >> my $dir = $1; >> - $dir =~ s/$config$// unless -d $dir; >> + $dir = dirname($dir) if -e $dir and !-d $dir; >> push @tries, grep -d $_, $dir, catdir $dir, 'bin'; > >may be just this? > > $dir = dirname $dir if -f $dir;
In one of the early versions of cygwin, if $dir is a symlink, -f would return 0, so I thought this might happen with some other platforms and I wanted just to make sure that $dir is not a dir :) Currently, this works right in the newer versions and I guess we can just use -f.
sure, let's keep it your way then, but please add a comment explaining that. Otherwise someone will "fix" it later.
-- __________________________________________________________________ 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]
