[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How much Unix should be simulated with GNU Make on VMS?

From: h.becker
Subject: Re: How much Unix should be simulated with GNU Make on VMS?
Date: Thu, 27 Mar 2014 12:22:36 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130519 Icedove/17.0.5

On 03/27/2014 12:31 AM, John E. Malmberg wrote:
> The GNU Make as is, can not execute the existing Unix makefiles on VMS
> because it has no knowledge of GNV or equivalent utilities and the
> default rules are changed.

Yes, GNU make on VMS has no knowledge of GNV (GNU's Not VMS). The
default rules for VMS are - more or less - VMS rules.

> And on VMS, while GNU make supports basic DCL commands, it does not
> fully support DCL commands, and the VMS specific changes actually
> interfere with other make features such as functions that expect space
> delimited arguments in a string.

I don't understand what the full support of DCL commands means in this
context. Symbol substitution as shown in the following pipe command?

> I have not found a way to make DCL symbol substitution work for using
> lexical functions in recipes.  I can build strings with lexical
> functions like you showed above, but I can not do:
>    pipe xx = "hello" ; write sys$$output "''xx'".
> It just writes out "''xs'".

That's a feature of lib$spawn, which GNU make on VMS uses for running
action routines. The forced symbol substitution is not done when using
lib$spawn with a single command, so the output is "''xx'" and not "".

What is the expected output of the above pipe command?
$ del/symb xx
%DCL-W-UNDSYM, undefined symbol - check validity and spelling
$ pipe xx = "hello" ; write sys$output "''xx'"

This indicates, that the symbol substitution is done when the command is
entered, not when the pipe command is executed.

(Btw. for this action MMK/MMS prints the expected empty string. You have
to have two actions to set the symbol xx and get hello printed. And that
works because MMK/MMS creates one subprocess for all the actions. [And
very likely feeds the actions into a mailbox which is DCL's input so DCL
can do the forced symbol substitution when reading the command.] GNU
make spawns a subprocess for each action. As usual there are pros and

> Some of the self tests issue "cat" commands (not with a macro), and
> these showed up in the test logs as failing because cat did not
> understand the VMS convention of using commas to separate the input
> files.  I have not figured out how it was running the Unix cat command,
> because I made cat a foreign command to run TYPE, and did not have a
> DCL$PATH set to find the coreutils cat program.  I had to modify the
> test to generate the makefile with a type command to verify what was
> being tested.

I understand, but I still would like to ask "Which cat?". The mix of
environments causes problems. That's somehow expected. There is no cat
command in VMS. A VMS cat would understand VMS conventions for input
files. GNU make for VMS has VMS conventions and GNV commands expect Unix
conventions. That will almost always create problems.

> Now from the readme.vms, I can see that there are users of this VMS
> mode.  The issue is that because it is mostly undocumented and has
> quirks, there is a risk that fixing what looks like an obvious bug could
> break what an existing makefile.vms is depending on.

No question, there are some quirks. It is used as-is and it seemed to be
enough for some users. I don't know how many there are. There were only
a few bug reports so far and I'm not convinced that there are only a few
bugs in the code.

> Now if you want to have a mostly VMS look and feel for the Makefile:
> There is another open source product MMK (Madgoat Make):
> https://github.com/endlesssoftware/mmk
> MMK issues a super set of the commercial MMS product original rules and
> macro set and better supports ODS-5 file names than the commercial MMS
> product.  Fully documented with its own documentation or you can use
> HP's documentation for MMS.

Me? I had to use MMK for a project and was not always happy. I dare to
say it has its own quirks.

> The recipe lines are pure VMS, and DCL is fully supported in what GNU
> make refers to as ONESHELL mode.  Which means that you can use DCL
> lexical functions, and create multiple line recipes to operate on a target.
> IMHO: If someone had to port a Unix makefile to VMS, using VMS specific
> syntax and tools, it is faster to write or convert to a MMK compatible
> makefile than it is to write a VMS variant of the makefile that runs on
> the existing GNU MAKE.
> Most of the Open Source products ported to VMS that I am aware of that
> use makefiles instead of DCL procedures, use the MMK variant, not GNU make.

If the current GNU make for VMS users want to switch to MMK or even MMS
that's fine with me.

> Now that the coreutils 8.21 and Bash 4.2.47 are available for VMS Alpha
> and IA64, we can now run the configure scripts and generate makefiles
> just like on UNIX, as long as we use the older forked port of GNU make.
> Unless you are building Bash, Coretuils, gnu sed, gawk, binutils, or
> make so you can not depend on them already existing, on VMS the UNIX
> format makefile can be both generated and run, which means that there
> must less reasons for manually maintaining a makefile.vms for any other
> project.
> And of the above set, only Gnu Make and binutils use a custom
> makefile.vms.  The rest use MMK to build them.
> But MMK is completely VMS specific, we need GNU Make in UNIX mode to use
> with GNV.

I'm not sure whether I understand all of this. But from the last
sentence I extract that GNV needs a GNU make running on VMS in UNIX
mode. Isn't that a totally different GNU make? What of the existing VMS
code base is really required? Wouldn't it make sense to leave the VMS
make as is and create a new variant, a GNU make for GNV?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]