> From: SMTP%"[EMAIL PROTECTED]" 20-APR-2000 17:48:19.51
> To:   PVHP
> CC:   
> Subj: RE: 5.6.0 install problems part 2
> 
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
> Precedence: bulk
> list-help: <mailto:[EMAIL PROTECTED]>
> list-unsubscribe: <mailto:[EMAIL PROTECTED]>
> list-post: <mailto:[EMAIL PROTECTED]>
> Delivered-To: mailing list [EMAIL PROTECTED]
> Mime-Version: 1.0
> X-Sender: [EMAIL PROTECTED]
> Message-Id: <p04310104b5254d4b077a@[192.168.56.172]>
> In-Reply-To: <[EMAIL PROTECTED]>
> References: <[EMAIL PROTECTED]>
> Date: Thu, 20 Apr 2000 19:42:07 -0500
> To: [EMAIL PROTECTED]
> From: "Craig A. Berry" <[EMAIL PROTECTED]>
> Subject: RE: 5.6.0 install problems part 2
> Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Content-Type: text/plain; charset="us-ascii"
> 
> At 5:00 PM -0700 4/20/00, [EMAIL PROTECTED] wrote:
> >Craig A. Berry wrote:
> > > 1). The Config variable 'version' is documented in Config.pm but it
> > > does not exist in my build.
> 
> >Dan and I patched around this a couple of times IIRC.
> 
> Well, looks like you guys did the hard part and forgot the easy part.
> All this stuff is collected but never written out, and I wouldn't
> swear that I've found all the missing ones.  Does this look right?:
> 
> --- vms/subconfigure.com;-0     Sun Mar 19 01:18:17 2000
> +++ vms/subconfigure.com        Thu Apr 20 19:58:56 2000
> @@ -4009,6 +4009,10 @@
>  $ WC "libc='" + perl_libc + "'"
>  $ WC "xs_apiversion='" + version + "'"
>  $ WC "pm_apiversion='" + version + "'"
> +$ WC "version='" + version + "'"
> +$ WC "revision='" + revision + "'"
> +$ WC "patchlevel='" + patchlevel + "'"
> +$ WC "subversion='" + subversion + "'"
>  $ WC "PERL_VERSION='" + patchlevel + "'"
>  $ WC "PERL_SUBVERSION='" + subversion + "'"
>  $ WC "pager='" + perl_pager +
> 
> That yields the following in config.sh; I'm building with the result now.
> 
> xs_apiversion='5_6_0'
> pm_apiversion='5_6_0'
> version='5_6_0'
> revision='5'
> patchlevel='6'
> subversion='0'
> PERL_VERSION='6'
> PERL_SUBVERSION='0'

When such questions have arisen I've found that going through a "good" unix
build can quickly provide an answer (whereas looking through the config units 
in Porting/ can be a little confusing though at times illuminating).  
Here, e.g. is a dec_osf config result:

% grep -i version config.sh
api_subversion='0'
api_version='5'
api_versionstring='5.005'
gccversion=''
ignore_versioned_solibs=''
inc_version_list='5.005/alpha-dec_osf 5.005'
inc_version_list_init='"5.005/alpha-dec_osf","5.005",0'
pm_apiversion='5.005'
subversion='0'
version='5.6.0'
xs_apiversion='5.005'
PERL_VERSION=6
PERL_SUBVERSION=0
PERL_API_VERSION=5
PERL_API_SUBVERSION=0

note the periods in version='5.6.0' but also note this passage from
the Bourne shell version of Configure:

$echo $n "(You have $package revision $revision" $c
$echo $n " patchlevel $patchlevel" $c
test 0 -eq "$subversion" || $echo $n " subversion $subversion" $c
echo ".)"
case "$osname" in
dos|vms)
        : XXX Should be a Configure test for double-dots in filenames.
        version=`echo $revision $patchlevel $subversion | \
                 $awk '{ printf "%d_%d_%d\n", $1, $2, $3 }'`
        api_versionstring=`echo $api_revision $api_version $api_subversion | \
                 $awk '{ printf "%d_%d_%d\n", $1, $2, $3 }'`
        ;;
*)
        version=`echo $revision $patchlevel $subversion | \
                 $awk '{ printf "%d.%d.%d\n", $1, $2, $3 }'`
        api_versionstring=`echo $api_revision $api_version $api_subversion | \
                 $awk '{ printf "%d.%d.%d\n", $1, $2, $3 }'`
        ;;
esac

So ironically there are parts of Configure that are set up to handle
vms.  Note that dos actually does run Configure under the djgpp port
of bash hence that case is needed there (to turn '5', '6', and '0' into 
'5_6_0', but '5.6.0' on unix like filesystems).

> > > 2).  The Config variable 'arch' is neither documented nor exists,
> >
> >Bummer - does putting a
> >
> >arch='VMS-AXP'
> >
> >line into config.sh before the initial mms to build perl help?
> 
> It turns out 'arch' existed in 5.005 but must have been deprecated;
> it's probably best to patch installperl to use 'archname'.

That would concur with the lack of an arch from my dec_osf config.sh:

% grep -i arch config.sh
archlib='/usr/local/lib/perl5/5.6.0/alpha-dec_osf'
archlibexp='/usr/local/lib/perl5/5.6.0/alpha-dec_osf'
archname64=''
archname='alpha-dec_osf'
archobjs=''
d_archlib='define'
d_vendorarch='undef'
installarchlib='/usr/local/lib/perl5/5.6.0/alpha-dec_osf'
installsitearch='/usr/local/lib/perl5/site_perl/5.6.0/alpha-dec_osf'
installvendorarch=''
multiarch='undef'
myarchname='alpha-dec_osf'
sitearch='/usr/local/lib/perl5/site_perl/5.6.0/alpha-dec_osf'
sitearchexp='/usr/local/lib/perl5/site_perl/5.6.0/alpha-dec_osf'
vendorarch=''
vendorarchexp=''

> > > 3).  After hacking around the previous two problems, I'm stuck on a
> > > stupid array problem
> >
> >$ type tt.pl
> >@a1 = ('XXXa','XXXb', 'XXXc');
> ># @array = map { s|^XXX||i } @a1;
> >@array = grep { s|^XXX||i } @a1;
> >print "@array\n";
> >$ perl tt.pl
> >a b c
> 
> Thanks, and to Brad for the explanation.  Whoever wrote the
> equivalent part of installperl was probably thinking grep and wrote
> map.  It does make me wonder whether this part of the install ever
> worked. 
> 
> I hope to have a patch out soon with all this stuff resolved.

Thank you.

Peter Prymmer

Reply via email to