Daniel Macks wrote:
On Wed, Aug 04, 2004 at 10:07:07AM -0700, Blair Zajac wrote:
The default CompileScript and InstallScript when Type: Perl is used contains the perlarchdir variable, which is expanded in PkgVersion.pm.
I'm building some Perl packages that use Module::Build instead of the standard Makefile.PL
There's an item in the Patches tracker that adds native Build.PL support to Type:perl. Seems like something we should have, given it's supposed increasing popularity.
and could use perlarchdir myself when I call this:
perl%type_raw[perl] Build.PL \
--install_path arch=%i/lib/perl5/%type_raw[perl]/`perl%type_raw[perl] -MConfig -e 'print $Config{archname}'` \
[...]
Yeah, that seems a bit hackish. Would probably look cleaner to assign to a variable first instead of on the Build.PL command itself, like:
#!/bin/sh -ev eval export "`perl -V:archname`" perl%type_raw[perl] Build.PL \ --install_path arch=%i/lib/perl5/%type_raw[perl]/${archname} \ [...]
Thanks. Made that change.
BTW, the I used -x instead of -v because I get to see the actual commands being used.
Also, all the output is directed to standard output except for the commands in the shell script, so I put a 'exec 2>&1' there.
Maybe we want to redirect standard error to standard output before calling the commands?
Also, I noticed that $perlarchdir is determined like this:
[in sub get_perl_dir_arch()...]
if ($perlversion ge "5.8.1") { $perlarchdir = 'darwin-thread-multi-2level'; } else { $perlarchdir = 'darwin'; }
I think a better way of doing this for future use would be just to use the Config{archname} value which generates the same values as this test, but would work regardless of what Apple does later in any future releases:
use Config: $perlarchdir = $Config{archname};
[coupla thoughts here; longish full brain-dump follows...]
That does seem a lot more generalizable. I wonder if it would lead to harder-to-debug problems with -pmXXX packages if a user has installed his own perlX.X.X with a different archdir config? Now, that situation fails (in his eyes) immediately: the script installs it in what fink thinks is archdir results in a module that is not accessible to his funky perl. Using Config{archname}, he'll get a working module, but installing precompiled .deb of -pmXXX will not work (NB: breakage of Fink policy that every fink gives compiles same .deb for everyone everytime everywhere). And later if he upgrades to fink's perlXXX, his modules will suddenly disappear.
Well, one way around this is to hardcode the path to the perl binary to use. Right now we just call perl or perl$version and hope for the best. If we always call /usr/bin/perl or /sw/bin/perl with or without the version number, then we don't even have to deal with a foreign perl unless the user goes to the effort of making a Fink perl package, which then hopefully will work.
Blair
-- Blair Zajac <[EMAIL PROTECTED]> Plots of your system's performance - http://www.orcaware.com/orca/
------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ Fink-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fink-devel
