Michael G Schwern <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 13, 2003 at 08:21:06PM -0800, David R. Morrison wrote:
> > Log Message:
> > Revise get_perl_dir_arch() and the places where it is used, correcting some
> > errors in UpdatePOD in case of Type: perl, and guaranteeing that the correct
> > perl command is used when needed.
>
> Wedging another return value into get_perl_dir_arch() doesn't seem the best
> of things to do here. In fact, it already does too much already. Instead,
> it looks like you need a get_perl() method.
>
> Also, you've eliminated the $Config{archname} check. Any reason?
>
I eliminated the get_perl() and ARCHNAME code completely from this routine.
One of the design philosophies of Fink is that, to the greatest extent
possible, different users compiling the same Fink package are supposed
to obtain identical deb files. The code for generating Fink-packaged
perl modules was designed with this in mind.
Prior to June, Fink's /sw/lib/perl5 was mimicking the layout which Apple
had used in their perl 5.6.0 installation, namely, storing things
directly in that directory or in /sw/lib/perl5/darwin. This caused
problems when people tried to upgrade, so in June we made a change
which allowed two different kinds of perlmodule packages: "Type: perl"
and "Type: perl 5.x.y". For backwards compatibility, the first kind
continued to be stored in /sw/lib/perl5 and /sw/lib/perl5/darwin while
the second kind used /sw/lib/perl5/5.x.y and /sw/lib/perl5/5.x.y/darwin.
We supply "/sw/lib/perl5" to @INC via the PERL5LIB environment variable,
and fortunately, this picks up /sw/lib/perl5/5.x.y automatically when
the perl being run is version 5.x.y. In this way, we get both the XS
modules and and the unversioned modules available, and the unversioned
ones only need to be compiled once for use in Fink by different versions
of perl.
The scheme was disrupted somewhat when Apple compiled perl 5.8.1 for 10.3
with a different architecture flag. So for "Type: perl 5.8.1" we now need
/sw/lib/perl5/5.8.1 and /sw/lib/perl5/5.8.1/darwin-thread-multi-2level.
The code which was formerly scattered around PkgVersion.pm but was recently
moved to get_perl_dir_arch() is designed to implement this. The decision
about where to store things needs to be made based on which "Type" of
package we have, not on what version of perl is currently running.
The same decision tree leads to a correct decision about which perl
executable to invoke when compiling the package: it should be the
fully path-qualified "perl" binary for "Type: perl", and the fully
path-qualified "perl5.x.y" binary for "Type: perl 5.x.y". Thus, it makes
sense to me to put that result into the same method call.
By the way, the versioned perl module packages are supposed to state
a build-time dependency on "perl5.x.y-core", which guarantees that the
appropriate binary is present to compile the package.
In addition to moving the $perlcmd code to get_perl_dir_arch(), I corrected
some implementation errors which had crept in as 2 or 3 different people
had modified that code in the past few months.
There is one residual problem with all of this. For backward
compatibility, we are still storing files for non-versioned perl modules
packages in /sw/lib/perl5 and /sw/lib/perl5/darwin. However, the
files in /sw/lib/perl5/darwin won't be found by perl 5.8.1. To get
around this, I'm thinking of having fink install a symlink
/sw/lib/perl5/darwin-thread-multi-2level -> /sw/lib/perl5/darwin.
Does this sound like a good idea?
-- Dave
-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/
_______________________________________________
Fink-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/fink-devel
