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
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
