You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Geoffrey Young <ge...@modperlcookbook.org> on 2004/08/06 14:44:41 UTC
APR_FIND_APR
hi all...
over in mod_perl land we are trying to figure out whether to call apr-config
or apr-$version-config, depending on which version of APR we are trying to
compile against. from the archives it looks like APR_FIND_APR is the
official way to do this, but it doesn't really help us lots since we're not
a configure based install and have to rely on a bunch of system() calls from
perl.
I hesitate to raise the issue again, since it looks like this was a
passionate subject before, but is it possible to roll up APR_FIND_APR into
its own, separate utility script or something? or maybe somebody else has
has a suggestion as to how we can intelligently figure out which utility
function to call?
not being familiar with the history here outside of the archives (which I
kinda got lost in), it seems pretty strange to have embedded the version in
the utility scripts rather than just adding a new --version parameter :)
--Geoff
Re: APR_FIND_APR
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, August 6, 2004 11:10 AM -0400 Joe Schaefer
<jo...@sunstarsys.com> wrote:
> mod_perl-2 should be getting the ap[ru] config script's
> name/location from httpd (ie apxs). Like apreq, modperl's
> apr ABI is subordinate to httpd, so asking apxs for the name
> of the ap[ru] script it used is IMO the safest solution.
apxs (in httpd-2.0 HEAD) already has the logic to handle the new apr-config
naming. -- justin
Re: APR_FIND_APR
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Geoffrey Young <ge...@modperlcookbook.org> writes:
[...]
> I guess what I was thinking about was someone who didn't care about mod_perl
> or httpd at all. that is, suppose I'm a user that simply wants perl
> bindings to APR - theoretically I could download only the APR/APU source and
> then build only the APR bindings, thus giving me only APR:: packages in
> site_perl, no httpd (or eventually whole mod_perl?) download required.
> isn't this the point of having perl's APR run outside of mod_perl?
In theory, sure. If APR were available independent of mp2, someone
could install it, and then mp2 could come along and install the version
*it* needs via MP_INST_APACHE2=1. Which is why I suggested making
this option mandatory some time ago.
However that doesn't solve the related problem of having parallel
installs of modperl-2 for both httpd-2.0 and httpd-2.2. But maybe
that's already taken care of by doing a local install of mp2 (assuming
PREFIX=/path/to/httpd-2.x/modules/perl actually works).
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: APR_FIND_APR
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>At the moment one can build Perl APR only by building mod_perl, so I
>>suppose apxs is fine for now.
>
>
> ok. so it looks like the way to handle this is via the new APR_VERSION and
> APU_VERSION queries. this is in apxs:
>
> my $apr_version = get_vars("APR_VERSION");
> $apr_version =~ s/(\d+)\.(\d).(\d)/$1/;
> my $apr_config="$apr_bindir/apr-$apr_version-config";
>
> so, in our code we would query apxs a second time via `apxs -q APR_VERSION`
> and if it succeeds then we insert the major number into the
> apr-$major-config, otherwise we assume apr-config.
The problem is that at the moment, we don't always have apxs. How are we
going to handle that when apxs is not available?
> rather than changing this now we can probably just work it into the planned
> refactoring.
post refactoring. I'm going to do it now.
>>Later on (after 2.0) is released we may provide a separate package which
>>will be buildable w/o mod_perl. Let's deal with that when we will want
>>to do that.
>
>
> less work is cool by me :)
>
> --Geoff
--
__________________________________________________________________
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
Re: APR_FIND_APR
Posted by Stas Bekman <st...@stason.org>.
Joe Schaefer wrote:
> Geoffrey Young <ge...@modperlcookbook.org> writes:
>
>
>>>At the moment one can build Perl APR only by building mod_perl, so I
>>>suppose apxs is fine for now.
>>
>>ok. so it looks like the way to handle this is via the new APR_VERSION and
>>APU_VERSION queries. this is in apxs:
>>
>> my $apr_version = get_vars("APR_VERSION");
>> $apr_version =~ s/(\d+)\.(\d).(\d)/$1/;
>> my $apr_config="$apr_bindir/apr-$apr_version-config";
>>
>>so, in our code we would query apxs a second time via `apxs -q APR_VERSION`
>>and if it succeeds then we insert the major number into the
>>apr-$major-config, otherwise we assume apr-config.
>
>
> Thankfully it's a lot easier now with the latest httpd-2.0 cvs:
>
> ----------------------------
> revision 1.62
> date: 2004/08/13 09:38:11; author: jorton; state: Exp; lines: +4 -11
> * configure.in, acinclude.m4: Substitute AP[RU]_CONFIG with location
> of installed ap[ru]-config scripts so third-party modules can use
> `apxs -q APR_CONFIG`.
>
> * support/apxs.in: Use new AP[RU]_CONFIG variables; use apr-config
> --apr-libtool.
> ----------------------------
>
> So you can just use something like
>
> $apr_config = `$apxs -q APR_CONFIG` ||
> `$apxs -q APR_BINDIR` . "/apr-config";
Nice! and we need to support older httpds as well.
Also I'd like to see us doing more caching at apxs calls, at the moment
mp2 configuration takes a way too much time. Besides it'd be nice to get
all these variables at once, and not one at a time (since it's a system
call for each of these).
--
__________________________________________________________________
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
Re: APR_FIND_APR
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Geoffrey Young <ge...@modperlcookbook.org> writes:
> > At the moment one can build Perl APR only by building mod_perl, so I
> > suppose apxs is fine for now.
>
> ok. so it looks like the way to handle this is via the new APR_VERSION and
> APU_VERSION queries. this is in apxs:
>
> my $apr_version = get_vars("APR_VERSION");
> $apr_version =~ s/(\d+)\.(\d).(\d)/$1/;
> my $apr_config="$apr_bindir/apr-$apr_version-config";
>
> so, in our code we would query apxs a second time via `apxs -q APR_VERSION`
> and if it succeeds then we insert the major number into the
> apr-$major-config, otherwise we assume apr-config.
Thankfully it's a lot easier now with the latest httpd-2.0 cvs:
----------------------------
revision 1.62
date: 2004/08/13 09:38:11; author: jorton; state: Exp; lines: +4 -11
* configure.in, acinclude.m4: Substitute AP[RU]_CONFIG with location
of installed ap[ru]-config scripts so third-party modules can use
`apxs -q APR_CONFIG`.
* support/apxs.in: Use new AP[RU]_CONFIG variables; use apr-config
--apr-libtool.
----------------------------
So you can just use something like
$apr_config = `$apxs -q APR_CONFIG` ||
`$apxs -q APR_BINDIR` . "/apr-config";
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: APR_FIND_APR
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> At the moment one can build Perl APR only by building mod_perl, so I
> suppose apxs is fine for now.
ok. so it looks like the way to handle this is via the new APR_VERSION and
APU_VERSION queries. this is in apxs:
my $apr_version = get_vars("APR_VERSION");
$apr_version =~ s/(\d+)\.(\d).(\d)/$1/;
my $apr_config="$apr_bindir/apr-$apr_version-config";
so, in our code we would query apxs a second time via `apxs -q APR_VERSION`
and if it succeeds then we insert the major number into the
apr-$major-config, otherwise we assume apr-config.
rather than changing this now we can probably just work it into the planned
refactoring.
> Later on (after 2.0) is released we may provide a separate package which
> will be buildable w/o mod_perl. Let's deal with that when we will want
> to do that.
less work is cool by me :)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: APR_FIND_APR
Posted by Stas Bekman <st...@stason.org>.
Geoffrey Young wrote:
>>The situation with APR is no different than say BerkeleyDB. You can't
>>have the perl glue compiled against one major version and expect it to
>>work in applications which are linked to another. Once httpd-2.2 comes
>>out, modperl-2 users that want to upgrade the new server must recompile
>>modperl-2, and because the libapr's are incompatible, that recompile
>>must include APR.
>
>
> I guess what I was thinking about was someone who didn't care about mod_perl
> or httpd at all. that is, suppose I'm a user that simply wants perl
> bindings to APR - theoretically I could download only the APR/APU source and
> then build only the APR bindings, thus giving me only APR:: packages in
> site_perl, no httpd (or eventually whole mod_perl?) download required.
> isn't this the point of having perl's APR run outside of mod_perl?
>
> now, sure, these APR:: classes wouldn't then work with a mod_perl built
> against a different httpd/apr, but the mod_perl install would overwrite the
> old ones anyway in a typical install.
>
> or maybe I'm just confused (which I seem to be alot lately, sorry).
At the moment one can build Perl APR only by building mod_perl, so I
suppose apxs is fine for now.
Later on (after 2.0) is released we may provide a separate package which
will be buildable w/o mod_perl. Let's deal with that when we will want
to do that.
--
__________________________________________________________________
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
Re: APR_FIND_APR
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> The situation with APR is no different than say BerkeleyDB. You can't
> have the perl glue compiled against one major version and expect it to
> work in applications which are linked to another. Once httpd-2.2 comes
> out, modperl-2 users that want to upgrade the new server must recompile
> modperl-2, and because the libapr's are incompatible, that recompile
> must include APR.
I guess what I was thinking about was someone who didn't care about mod_perl
or httpd at all. that is, suppose I'm a user that simply wants perl
bindings to APR - theoretically I could download only the APR/APU source and
then build only the APR bindings, thus giving me only APR:: packages in
site_perl, no httpd (or eventually whole mod_perl?) download required.
isn't this the point of having perl's APR run outside of mod_perl?
now, sure, these APR:: classes wouldn't then work with a mod_perl built
against a different httpd/apr, but the mod_perl install would overwrite the
old ones anyway in a typical install.
or maybe I'm just confused (which I seem to be alot lately, sorry).
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: APR_FIND_APR
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Geoffrey Young <ge...@modperlcookbook.org> writes:
> moving this particular thread to dev@perl...
>
> > mod_perl-2 should be getting the ap[ru] config script's
> > name/location from httpd (ie apxs). Like apreq, modperl's
> > apr ABI is subordinate to httpd, so asking apxs for the name
> > of the ap[ru] script it used is IMO the safest solution.
>
> is this really true? I would have thought that for all the work that was
> being done to make the APR:: classes run outside of mod_perl the next
> logical step would be to not rely on people getting APR from httpd at all.
> but I haven't been really paying attention to the APR work lately
> (unfortunately).
The situation with APR is no different than say BerkeleyDB. You can't
have the perl glue compiled against one major version and expect it to
work in applications which are linked to another. Once httpd-2.2 comes
out, modperl-2 users that want to upgrade the new server must recompile
modperl-2, and because the libapr's are incompatible, that recompile
must include APR.
--
Joe Schaefer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: APR_FIND_APR
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
moving this particular thread to dev@perl...
> mod_perl-2 should be getting the ap[ru] config script's
> name/location from httpd (ie apxs). Like apreq, modperl's
> apr ABI is subordinate to httpd, so asking apxs for the name
> of the ap[ru] script it used is IMO the safest solution.
is this really true? I would have thought that for all the work that was
being done to make the APR:: classes run outside of mod_perl the next
logical step would be to not rely on people getting APR from httpd at all.
but I haven't been really paying attention to the APR work lately
(unfortunately).
so yes, getting the info from apxs is easiest, especially now that I see
apxs in 2.1 supports an AP(R|U)_VERSION query, so we can dig out the script
name ourselves. but I would have thought we would want a solution that
works outside of apxs (eventually, anyway :)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: APR_FIND_APR
Posted by Joe Schaefer <jo...@sunstarsys.com>.
Geoffrey Young <ge...@modperlcookbook.org> writes:
> I hesitate to raise the issue again, since it looks like this was a
> passionate subject before, but is it possible to roll up APR_FIND_APR
> into its own, separate utility script or something? or maybe somebody
> else has has a suggestion as to how we can intelligently figure out
> which utility function to call?
mod_perl-2 should be getting the ap[ru] config script's
name/location from httpd (ie apxs). Like apreq, modperl's
apr ABI is subordinate to httpd, so asking apxs for the name
of the ap[ru] script it used is IMO the safest solution.
> it seems pretty strange to have embedded the version in
> the utility scripts rather than just adding a new --version parameter :)
Not strange at all when you consider parallel installs of past 0.9.x and
future 1.x.y.
--
Joe Schaefer