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} \
[...]
> Could we add %{perlarchdir} to expand in .info files?
It seems pretty special-purpose, especially since there are already
ways to get this info (several methods to access Config, or with some
shell if/then based on %type_raw[perl]).
> 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.
I doubt (but don't know for certain) that Apple would make such a
major change as perl archdir for an already-extant /usr/bin/perl since
that would break many people's systems. I also suspect that a perl
version upgrade would only happen as part of a larger system (kernel)
upgrade. Fink already throws a warning when being installed on an OS
version for which that fink version has not been tested, and that
gives us the opportunity to push a new fink release that knows about
whatever wacky things Apple does in the new OS. I wonder if fink
should check this at fink runtime, since one could upgrade OS but not
fink and then be in an "untested" state?
Also, reading the value of Config{archdir} in get_perl_dir_arch()
(vs. returning something constant by if/then or a bit of script to
read archdir when the script is eventually run) makes the *Script
field itseld only determined at actual build-time. That is a big (IMO)
change from the current situation. When debugging variants and when
trying to compile "by hand" based on a fink package template, I like
being able to query fink "what script would you use?" and not have to
install a perl that I might not even be using just to find out.
dan
--
Daniel Macks
[EMAIL PROTECTED]
http://www.netspace.org/~dmacks
-------------------------------------------------------
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
