perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: Some small fixes...
Date Mon, 16 May 2005 14:51:28 GMT
Nick *** wrote:
[...]
>  >> 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.
>  >
> 
> I don't think the things may get more complicated, because these arguments are already
there. Sure, they are unusable, but doesn't this make things more complicated for people,
who want to build a static perl and want to use their apr? They see the option, but they can't
use it. Strange, isn't it? Maybe for those people, who are going to
> mess up with many options without knowing what they are doing, there can be a statement
that these options are optional.

Hmm, when you build a static httpd/mod_perl, do you tell apache to use 
your preinstalled httpd and not the one in the source. If that's the case, 
then your proposal makes a lot of sense, Nick. If not, then it doesn't, 
since httpd will be linked agaist libapr it will build by itself.

>  >>  >> 3. A better check whether --with-apr=/path is a file

> Index: lib/Apache2/Build.pm
> ===================================================================
> --- lib/Apache2/Build.pm	(revision 170253)
> +++ lib/Apache2/Build.pm	(working copy)
> @@ -1122,7 +1122,11 @@
>              if ($self->{MP_AP_CONFIGURE} &&
>                  $self->{MP_AP_CONFIGURE} =~ /--with-${what_long}=(\S+)/) {
>                  my $dir = $1;
> -                $dir =~ s/$config$// unless -d $dir;
> +                
> +                # Just make sure $dir is not a directory.
> +                # On some rare cases with older versions of perl and Cygwin,
> +                # -f might not return what's expected.
> +                $dir = dirname($dir) if -e $dir and !-d $dir;
>                  push @tries, grep -d $_, $dir, catdir $dir, 'bin';
>              }
>          }

Great. But we can't commit anything now as we are in the code freeze. So 
we will put it in after 2.0.0 release in a day or two. If this is not 
committed, please remind us. Thanks a lot Nick.

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message