[Top][All Lists]

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

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

From: John E. Malmberg
Subject: How much Unix should be simulated with GNU Make on VMS?
Date: Wed, 26 Mar 2014 18:31:42 -0500
User-agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3

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):

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.


reply via email to

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