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

[John E. Malmberg]

Starting fresh thread instead of continuing the bug 41813 discussion.

> On 03/20/2014 11:32 PM, John E. Malmberg wrote:

> > Another question is how much of the Unix environment should be simulated
> > when running Gnu make from DCL?
>
> In my local copy of the sources, I changed the ECHO variable defined in
> default.c to builtin_echo, which I implemented in vmsjobs.c as a simple
> wrapper for write sys$output. That way, whatever worked for VMS/DCL
> users with $(ECHO) will work, even with multilines.
>
> OK there are a few exceptions. If someone knew that there was a missing
> double quote and coded $(ECHO) hello" the old output was hello and the
> new output will be hello". Also, if someone wanted to use DCL
> symbols/lexcials and knew that $(ECHO) "+f$$time() would get the wanted
> result, the new code will give a %DCL-W-EXPSYN and the code has to
> change to $(ECHO) "+f$$time()+ to get the wanted result.
>
> I don't know of anything of a Unix environment which should be
> simulated, here. But obviously there is no parity. In Unix you can have
> a shell variable in the to be echoed text and - if defined - it will
> show. As I showed in the above example, it's not that intuitive/easy for
> VMS/DCL symbols.

GNU Make on VMS is currently a combination of Unix specific macros, 
simulated Unix commands and quite a few mostly undocumented VMS specific 
changes.

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.

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 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'".

So there is no question about the existing port have a mostly VMS flavor 
of doing things.  It has a mostly Unix flavor of doing things.

So parts of Unix are being simulated, but as the test failures show, 
there are still many parts that are not, but probably could easily be 
simulated.

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.

Unless there is something going on that I have not discovered, it looks 
like the cat utility is being internally simulated, at least on VMS.


I am currently trying to summarize what I learned from getting the test 
harness to run as a section in the readme.vms better document the 
current behavior.

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.


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.

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.

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.

Regards,
-John