On Thu, 19 Apr 2001, Martin Vorlaender wrote:
> > Were you seeing the informational message before?
>
> Nope, the only thing I saw was
>
> Checking to see if you have long double...
> You have long double.
> Checking to see how big your long doubles are...
> Your long doubles are bytes long.
>
> as it would be if just_mcr_it didn't set the tmp symbol
> (after having initialized it to "").
alright.
> > > > Or should we make long doubles undef in this case? It
> > > > doesn't seem like they'd offer any real advantage.
> > >
> > > As I can't oversee the implications: Dunno.
> >
> > You might try running `mms test` in separate builds with d_longdbl =
> > "define" and d_longdbl = "undef" to see if there is a measurable
> > difference in timing (assuming that there are no tests that probe the
> > value of $Config{d_longdbl} and run a harder set of tests if
> > the value is matches /define/i).
>
> Stand by, please... (oh, if I had all the time I wish I had...)
Hehe - I know the feeling all too well.
> > Perhaps we need to modify it to something like the following:
> >
> > # install ought not need a source, but it doesn't work if one's not
> > # there. Go figure...
> > install : $(MINIPERL_EXE)
> > @ @perl_setup.com
> > If F$TrnLnm("Sys") .nes. "" Then Deass SYS
> > create/directory perl_root:[lib]
> > copy $(DBG)perl$(E) perl_root:[000000]
> > copy $(DBG)perlshr$(E) perl_root:[000000]
> > $(MINIPERL) installperl
> >
> > And make suitable changes to installperl so as not to double install
> > perl.exe and perlshr.exe (I suspect it'd be nice to avoid PURGE).
>
> The problem already is with the call to perl_setup.com
> (where the dreaded $ SET COMMAND is issued).
>
> When building perl, I circumvented it by modifying perl_setup (I
> don't use it anyway - my perl command is in the systemwide DCL
> table). But I'll look into a more concise way to solve the
> problem (please stand by - see above <sigh>).
That sounds like a real bug in configure.com. It is supposed to ask this
question if you will not be using a foreign symbol:
$ IF (.NOT.perl_symbol)
$ THEN
$ dflt = "y"
$ IF .NOT.silent
$ THEN
$ echo ""
$ echo "Since you won't be using a symbol you must choose to put the ''packageup'"
$ echo "verb in a per-process table or in the system wide DCLTABLES (which"
$ echo "would require write privilege)."
$ ENDIF
$ rp = "Invoke perl as a per process command verb? [ ''dflt' ] "
$ GOSUB myread
$ IF (.NOT.ans).AND.(ans.NES."")
$ THEN perl_verb = "DCLTABLES"
$ ELSE perl_verb = "PROCESS"
$ ENDIF
$ ENDIF ! (.NOT.perl_symbol)
and then later on it writes out perl_setup.com like so:
$ IF perl_verb .EQS. "PROCESS"
$ THEN
$ WRITE CONFIG "$ set command ''vms_prefix':[000000]''packageup'.CLD"
$ ENDIF
Hence there should not be a "$ set command" line in your perl_setup.com
if you told configure.com that you wanted to use the system wide
DCLTABLES. Can you please determine how configure.com is messing this up?
I should be able to fold in change requests to an upcoming patch.
Unfortunately I almost never use a perl command verb, whether via SET
COMMAND or by placing it into DCLTABLES.EXE hence I don't have any test
platforms for PERL as verb and could use some help in modifying
configure.com to suit your needs. Thank you.
Peter Prymmer
