On Wed, 18 Apr 2001, Martin Vorlaender wrote:
> Craig A. Berry <[EMAIL PROTECTED]> wrote:
> > Martin Vorlaender wrote:
> > >- The configuration test for long doubles gives
> > <snip>
> > > %CC-I-LONGDOUBLENYI, In this statement, type long
> > double has the same
> > > representation as type double on this platform.
> > <snip>
> > > $ write sys$output $status
> > > %X10B90003
> > >
> > > As CONFIGURE.COM only tests for %X10B90001, it does detect the
> > > presence of long doubles, but fails to get the size. Not sure
> > > how to resolve this.
> >
> > I don't have a way to test this, but something like this
> > could work;
>
> Errr, wait a moment:
>
> $ write sys$output f$message(%X10B90003)
> %CC-I-NORMAL, normal successful completion
>
> The trouble really is with just_mcr_it, which won't recognize
> %X10B90003 as a successful compile, and thus won't run the program.
> A better solution would probably be to redefine compile_status
> (sorry, got no diff/patch here yet):
>
> $ echo4 "Checking to see if you have long double..."
> $ GOSUB link_ok
> $ IF link_status .NE. good_link
> $ THEN
> ...
> $ ELSE
> $ echo "You have long double."
> $ echo4 "Checking to see how big your long doubles are..."
> $ IF compile_status .EQ. %X10B90003 THEN compile_status = good_compile !!!
> $ GOSUB just_mcr_it
> $ longdblsize = tmp
> $ d_longdbl = "define"
> $ echo "Your long doubles are ''longdblsize' bytes long."
> $ ENDIF
That looks good - does it work correctly for you? Were you seeing the
informational message before?
> > 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).
> > >- If you go with the DCL tables verb (instead of the foreign command),
> > > "MMK INSTALL" fails, because it wants to SET COMMAND the PERL.CLD
> > > file from PERL_ROOT:[000000] - which doesn't exist. I suppose
> > > SYS$DISK:[] would suffice here.
> >
> > Hmm. Does this problem go away if you create the top-level
> > directory before the install?
>
> No, but if I copy PERL.CLD to PERL_ROOT:[000000] before calling
> MMK INSTALL (which calls PERL_SETUP.COM, which issues the
> $ SET COMMAND PERL_ROOT:[000000]PERL.CLD)...
One might be tempted to have the install target in the descrip.mms
file do this prior to running the installperl script, perhaps conditional
upon the notion that you requested. The current install target looks
like:
# 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
$(MINIPERL) installperl
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).
Peter Prymmer
