From @nwc10

On VMS, if I run configure.com as

  @​configure "-des" "-Dusedevel" "-Dusevmsdebug"

then it will tell me to invoke mmk as

  mmk "/macro=(__DEBUG__)"

This works.

However, if I invoke mmk as just mmk it doesn't. The build gets a log way,
then fails like this​:

running PTAC$DKA0​:[NCLARK.I.perl5191]MINIPERL.EXE;1 "-I[--.lib]" "ppport_h.PL"
installing ppport.h for cpan/DB_File
installing ppport.h for cpan/IPC-SysV
installing ppport.h for cpan/List-Util
installing ppport.h for cpan/Time-HiRes
installing ppport.h for cpan/Win32API-File
installing ppport.h for dist/Cwd
removing temporary file PPPort.pm
removing temporary file ppport.h
MCR Sys$Disk​:[]miniperl.exe "-I[.lib]" "-I[.dist.Cwd]" "-I[.dist.Cwd.lib]" make_
ext.pl "MAKE=MMK" "--dynamic" "--static"
  Making Cwd (all)

Creating Makefile.PL in dist/Cwd for Cwd

Running Makefile.PL in dist/Cwd
PTAC$DKA0​:[NCLARK.I.perl5191]MINIPERL.EXE;1 "-I../../lib" "Makefile.PL" "INST_LI
B=[--.lib]" "INST_ARCHLIB=[--.lib]" "PERL_CORE=1"
Writing Descrip.MMS for Cwd
Making all in dist/Cwd
MMK all /DESCRIPTION=descrip.mms /MACRO=("PERL_CORE=1")
cp [.lib.File.Spec]Mac.pm [--.lib.File.Spec]Mac.pm
cp [.lib.File.Spec]Cygwin.pm [--.lib.File.Spec]Cygwin.pm
cp [.lib.File]Spec.pm [--.lib.File]Spec.pm
cp [.lib.File.Spec]Unix.pm [--.lib.File.Spec]Unix.pm
cp [.lib.File.Spec]OS2.pm [--.lib.File.Spec]OS2.pm
cp [.lib.File.Spec]Win32.pm [--.lib.File.Spec]Win32.pm
cp [.lib.File.Spec]Functions.pm [--.lib.File.Spec]Functions.pm
cp [.lib.File.Spec]VMS.pm [--.lib.File.Spec]VMS.pm
cp [.lib.File.Spec]Epoc.pm [--.lib.File.Spec]Epoc.pm
cp cwd.pm [--.lib]cwd.pm
MCR [--]miniperl.exe "-I[--.lib]" "-I[--.lib]" -e "use ExtUtils​::Mksymlists;"
-e "Mksymlists('NAME' => 'Cwd', 'DL_FUNCS' => { }, 'DL_VARS' => [], 'FUNCLIST'
=> [])"
MCR [--]miniperl.exe -e "print ""[--.lib.auto.Cwd]Cwd.olb/Include=Cwd\n[--.lib.a
uto.Cwd]Cwd.olb/Library\n"";" >>CWD.OPT
MCR [--]miniperl.exe -e "print qq{DBGPerlShr/Share\n}" >>CWD.OPT
MCR PTAC$DKA0​:[NCLARK.I.perl5191]miniperl.exe "-I[--.lib]" "-I[--.lib]" "-MExtUt
ils​::Command" -e "cp" "--" CWD.OPT [--.LIB.AUTO.CWD]CWD.OPT
MCR [--]miniperl.exe "-I[--.lib]" "-I[--.lib]" [--.lib.ExtUtils]xsubpp -nolinen
umbers -typemap [--.lib.ExtUtils]typemap CWD.xs >CWD.C
CC/DECC /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj /NOANSI_ALIAS/floa
t=ieee/ieee=denorm/NAMES=(SHORTENED)/Define=(_USE_STD_STAT=1,"VERSION=""3.41""",
"XS_VERSION=""3.41""")/Include=([--])/List/Debug/NoOpt CWD.c
If F$Search("[--.LIB.AUTO.CWD]CWD.OLB").eqs."" Then Library/Object/Create [--.LI
B.AUTO.CWD]CWD.OLB
Library/Object/Replace [--.LIB.AUTO.CWD]CWD.OLB CWD.OBJ
%MMK-F-CANTUPD, cannot update target [--]DBGPERLSHR.EXE - sources unknown
%MMK-F-CANTUPD, cannot update target [--]DBGPERLSHR.EXE - sources unknown
Unsuccessful make(dist/Cwd)​: code=1024 at make_ext.pl line 490.
%NONAME-F-NOMSG, Message number 0C14805C
%MMK-F-ERRUPD, error status %X0C14805C occurred when updating target DYNEXT

The DESCRIP.MMS generated by @​configure "-des" "-Dusedevel" "-Dusevmsdebug"
is identical to that from @​configure "-des" "-Dusedevel"

So, why is it that the former's build doesn't work without
mmk "/macro=(__DEBUG__)"?

(I'm guessing something in config.sh)

And if it's not sensible to make it work without the "/macro=(__DEBUG__)",
then would it be better to generate a different DESCRIP.MMS that implicitly
adds __DEBUG__, and save the user having to type something that's actually
mandatory?

This is blead somewhat more recent than v5.19.1, but I don't know the
commit offhand, and I don't know the VMS equivalent of ./myconfig
(On the HP Opensource Itanium)

Nicholas Clark

From @craigberry

On Wed, Jun 12, 2013 at 10​:44 AM, Nicholas Clark
<perlbug-followup@​perl.org>wrote​:

# New Ticket Created by Nicholas Clark
# Please include the string​: [perl #118447]
# in the subject line of all future correspondence about this issue.
# <URL​: https://rt-archive.perl.org/perl5/Ticket/Display.html?id=118447 >

On VMS, if I run configure.com as

@​configure "\-des" "\-Dusedevel" "\-Dusevmsdebug"

then it will tell me to invoke mmk as

mmk "/macro=\(\_\_DEBUG\_\_\)"

This works.

However, if I invoke mmk as just mmk it doesn't. The build gets a log way,
then fails like this​:

<snip>

CC/DECC /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=.obj
/NOANSI_ALIAS/floa

t=ieee/ieee=denorm/NAMES=(SHORTENED)/Define=(_USE_STD_STAT=1,"VERSION=""3.41""",
"XS_VERSION=""3.41""")/Include=([--])/List/Debug/NoOpt CWD.c
If F$Search("[--.LIB.AUTO.CWD]CWD.OLB").eqs."" Then Library/Object/Create
[--.LI
B.AUTO.CWD]CWD.OLB
Library/Object/Replace [--.LIB.AUTO.CWD]CWD.OLB CWD.OBJ
%MMK-F-CANTUPD, cannot update target [--]DBGPERLSHR.EXE - sources unknown
%MMK-F-CANTUPD, cannot update target [--]DBGPERLSHR.EXE - sources unknown
Unsuccessful make(dist/Cwd)​: code=1024 at make_ext.pl line 490.
%NONAME-F-NOMSG, Message number 0C14805C
%MMK-F-ERRUPD, error status %X0C14805C occurred when updating target DYNEXT

The DESCRIP.MMS generated by @​configure "-des" "-Dusedevel" "-Dusevmsdebug"
is identical to that from @​configure "-des" "-Dusedevel"

So, why is it that the former's build doesn't work without
mmk "/macro=(__DEBUG__)"?

Technically it is not the top-level descrip.mms that has trouble but the
descrip.mms generated for the extension build.

(I'm guessing something in config.sh)

Yes, specifically the usevmsdebug='define' in config.sh that is telling
EUMM to generate a descrip.mms for the extension that looks for a
differently-named debug shareable image to link against.

And if it's not sensible to make it work without the "/macro=(__DEBUG__)",
then would it be better to generate a different DESCRIP.MMS that implicitly
adds __DEBUG__, and save the user having to type something that's actually
mandatory?

I think what happened is that the debug option was originally a
command-line macro and was completely independent of the configuration
process. Then someone noticed that the debug compile and link flags were
not getting propagated to extension builds, so the configuration option and
EUMM changes were made to accomplish that. But without changing the way
the top-level descrip.mms finds out what kind of build is being requested.
And that all probably happened in the last century and I've never bothered
to change it.

But I can't really think of any good reason to leave it as is and it should
be an easy change to add one more symbol expansion the configuration
process. I'll look into it soonish.

This is blead somewhat more recent than v5.19.1, but I don't know the
commit offhand, and I don't know the VMS equivalent of ./myconfig
(On the HP Opensource Itanium)

$ mcr []miniperl -"Ilib" -"V"

or

$ [.vms]myconfig.com

should do the trick (though the latter is very stale based on its comments).

And once you get your debug perl built, you'll get to deal with a debugging
environment that, like everything else on VMS, is completely different even
when similar in principle to whatever else you're used to, so you may need
the manual at​:

<http​://h71000.www7.hp.com/doc/84final/4538/ba554_90016.pdf>

and I'll be happy to put together a cheat sheet if you give me an idea of
what you're doing, e.g., what you want to break on, etc.

The RT System itself - Status changed from 'new' to 'open'

From @craigberry

On Wed, Jun 12, 2013 at 12​:42 PM, Craig A. Berry <craig.a.berry@​gmail.com>wrote​:

But I can't really think of any good reason to leave it as is and it
should be an easy change to add one more symbol expansion the configuration
process. I'll look into it soonish.

Done as of <
http​://perl5.git.perl.org/perl.git/commitdiff/9152021db0fe677bcc7f8460e5d5419a79462abc

.

From @nwc10

On Wed, Jun 12, 2013 at 12​:42​:45PM -0500, Craig A. Berry wrote​:

But I can't really think of any good reason to leave it as is and it should
be an easy change to add one more symbol expansion the configuration
process. I'll look into it soonish.

Thanks. I see that you did this with commit 9152021.
But that commit didn't remove the various __DEBUG__ sections from the
template. Is that correct - ie is there still a reason/use for invoking
mmk with /MACRO=__DEBUG__ ?

This is blead somewhat more recent than v5.19.1, but I don't know the
commit offhand, and I don't know the VMS equivalent of ./myconfig
(On the HP Opensource Itanium)

$ mcr []miniperl -"Ilib" -"V"

or

$ [.vms]myconfig.com

should do the trick (though the latter is very stale based on its comments).

ah OK thanks.

And once you get your debug perl built, you'll get to deal with a debugging
environment that, like everything else on VMS, is completely different even
when similar in principle to whatever else you're used to, so you may need
the manual at​:

<http​://h71000.www7.hp.com/doc/84final/4538/ba554_90016.pdf>

and I'll be happy to put together a cheat sheet if you give me an idea of
what you're doing, e.g., what you want to break on, etc.

I wasn't trying to debug the C code on VMS. I was trying to *not* break
the build while refactoring how and when lib/sitecustomize.pl got built.
In the process of which I discovered that there seemed to be two rules to
build MINIPERL.EXE.

I think that I got it all straight as I merged it to blead. (And as Sprout
discovered, I inadvertently made the Unix build very fragile if you break
miniperl early enough. Oops. Had that happen to me too before, and it's not
fun)

This was all related to untwisting the build to get Zefram's File​::Spec in
XS bootstrapping. Which it should do. But in the process I noticed that
there is still vms/ext

Is it OK to remove the +x from vms/ext/filespec.t?
And to move it and Filespec.pm into ext/vms?

It's all in the branch smoke-me/nicholas/vms-filespec
(which also depends on the Configure patch to add nonxs_ext to
known_extensions).

It works for me on the VMS testdrive system, and all the smokers seem happy
with it.

I'm not sure what "cheatsheet" I'd benefit from :-)
I'm still having "problems" with rm -rf
In that

* I can run rm -rf from bash but it doesn't delete files which are read-only
  (I believe because of the mapping of Unix rwx 3-way permissions to the VMS
  4-way permissions including delete)
* I can use the installed perl 5.8.6 with File​::Path to rmtree, which does
  know how to delete read-only files, but in turn *that* doesn't cope with
  multiple dots in filenames
* xargs in the GNV bash SEGVs. As does using -exec in find
* the GNV bash won't read commands from a pipe

but with some combination of the above, sed and temporary files, I can
actually delete stuff.

I did have a counter-cheat sheet​:

1) this makes a tarball named after the current revision​:

commit=`git rev-parse --short=12 HEAD`; tar cf perl-$commit.tar --files-from <(sed -e 's/[ ].*//' MANIFEST) --transform 's!^!perl-'$commit'/!'

(requires GNU tar, which I think *BSD and OS X also ship. There's a literal
tab in there)

2) Putty's scp is excellent, as it speaks the sftp protocol and hence works
  with the SSH2 based server on VMS

I don't think I said - I saw Simon Tatham a while back and said thanks for
putty, as it was really useful for (of all things) VMS. And he initially
guessed wrongly as to why. He assumed that I was finding its terminal
emulation excellent. He said that before he retired, his father worked with
VMS systems, and so was one of the early Putty users and testers, with
the result that the VMS specific stuff got a lot of feedback. :-)

Nicholas Clark

From @craigberry

On Wed, Jun 19, 2013 at 10​:07 AM, Nicholas Clark <nick@​ccl4.org> wrote​:

On Wed, Jun 12, 2013 at 12​:42​:45PM -0500, Craig A. Berry wrote​:

But I can't really think of any good reason to leave it as is and it should
be an easy change to add one more symbol expansion the configuration
process. I'll look into it soonish.

Thanks. I see that you did this with commit 9152021.
But that commit didn't remove the various __DEBUG__ sections from the
template. Is that correct -

Yes.

ie is there still a reason/use for invoking
mmk with /MACRO=__DEBUG__ ?

No.

What I changed is that the new line in vms/descrip_mms.template that
looks like USEVMSDEBUG is now replaced by one of two things when
configure.com translates the template into the top-level descrip.mms.
If you have *not* configured with -Dusevmsdebug, it gets replaced by a
blank line. If you *have* configured with -Dusevmsdebug, it gets
replaced with __DEBUG__=1.

So the macro gets defined (or not) based on how you configure and
there is no longer any reason to specify it on the command line. The
things that *reference* the macro are still necessary to produce a
debug build.

Is it OK to remove the +x from vms/ext/filespec.t?

Should be.

And to move it and Filespec.pm into ext/vms?

This is potentially dodgy because you can't run a Makefile.PL without
it, but I think you covered that by putting the new location in
buildcustomize.pl, so as long as we're running miniperl it should be
ok.

I'm not sure what "cheatsheet" I'd benefit from :-)
I'm still having "problems" with rm -rf

I think the system you are using is at VMS v8.4, which means you
should be able to do (from DCL)​:

$ delete/tree [.perl-<commit-id>...]*.*;*

where <commit-id> is replaced with the actual name that is part of the
top-level directory you are trying to delete.

I did have a counter-cheat sheet​:

1) this makes a tarball named after the current revision​:

commit=`git rev-parse --short=12 HEAD`; tar cf perl-$commit.tar --files-from <(sed -e 's/[ ].*//' MANIFEST) --transform 's!^!perl-'$commit'/!'

I would think git archive would be easier but I'm probably missing
some part of your intent.

2) Putty's scp is excellent, as it speaks the sftp protocol and hence works
with the SSH2 based server on VMS

Indeed. Since you made me aware of it, I regularly use pscp from OS X
and Windows to exchange files with VMS systems.

I don't think I said - I saw Simon Tatham a while back and said thanks for
putty, as it was really useful for (of all things) VMS. And he initially
guessed wrongly as to why. He assumed that I was finding its terminal
emulation excellent. He said that before he retired, his father worked with
VMS systems, and so was one of the early Putty users and testers, with
the result that the VMS specific stuff got a lot of feedback. :-)

Interesting story :-).

This kinda looks like the original issue was resolved by 9152021