Re: [mp2] DESTDIR does not apply to mod_perl.so and includes

[prev] [thread] [next] [Date index for 2005/02/09]

Nick Phillips wrote:
> On 08/02/2005, at 4:16 PM, Stas Bekman wrote:
> 
>> sure, but you can help us figure out a solution w/o knowing anything 
>> about mod_perl. The situation of the packagers is unique. One can 
>> think of it as if they are using chroot(1), where their / moves 
>> elsewhere. It'd be easy to make DESTDIR supported, but this is not the 
>> right thing. mod_perl has to be installed where all other Apache 
>> modules are. So DESTDIR must not affect it. Notice that unlike mp1, 
>> mp2 does not install mod_perl.so under the perl tree.
> 
> 
> What's DESTDIR do currently? The "standard" thing for DESTDIR to do is 
> to cause
> files to be installed to a different location, irrespective of where 
> libs etc.
> are going to be searched for, and irrespective of whether or not it has a
> snowball's chance in hell of actually working in that location.
> 
> It makes life easy for a packager, and it allows anyone else to see 
> *exactly*
> what "make install" would do were DESTDIR not set.
> 
> So my first reaction to your saying "So DESTDIR must not affect it" is 
> "that
> doesn't follow". Hence asking what it actually does at the moment.

DESTDIR is a perl thingy. It will send all perl bits to DESTDIR.

mod_perl.so and its .h files are not perl thingies, and so DESTDIR doesn't 
apply here by design. Simply because Apache thingies live under the Apache 
tree, not the perl tree.

>> I suppose the simplest solution to this problem is to provide a new 
>> Makefile.PL argument, which will be the same as DESTDIR in the perl 
>> world, but for Apache things. e.g., MP_AP_DESTDIR, so if specified it 
>> can be used exactly as in your patch above. (handling the trailing 
>> slash of ofcourse). In your case MP_AP_DESTDIR will be the same value 
>> as DESTDIR.
> 
> 
> In the universe I come from, DESTDIR should not affect anything during the
> actual build, just during the install. And it should affect 
> *everything*. If
> you also want a setting that will enable things to be installed 
> somewhere else
> *and work*, then you do need another setting. But in my universe, it's 
> *that*
> one that should be called something else. It seems from what I remember 
> to be
> more similar to autotools' ${prefix}.

Welcome to the new dimension where your perl universe meets an apache 
universe and where the two overlap F=mg doesn't always apply.

The mod_perl project is a glue between these two universes. mod_perl.so 
and modperl*.h live in the Apache universe, whereas 
(Apache|ModPerl|APR)::* modules live in the Perl universe, and therefore 
they get installed into different places.


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