Re: VAX/VMS 7.3 and build from copy of master.

[h.becker]

On 02/25/2014 01:36 AM, John E. Malmberg wrote:
> ...
>> Then the VMS command procedure and the makefile.vms have to change and
>> copy from config-h-vms. instead of config.h-vms. Not really nice but
>> managable. Then there is an entry for config.h-vms in .gitignore, which
>> would need to change as well. Am I missing something else?
> 
> VMS does not always like files with no extensions.  Probably would not
> be an issue here.

Probably not (and VMS file names by definition always have a file
extension).

> Because computers work for us, not us for computers.  So if the script
> can figure out a step to be done, there is no reason for to have it as
> an extra manual step.  We should have one command file that completely
> build GNU make, not several steps.

>From the released tarball: yes; from the snapshot: no. It is still my
opinion that building from the snapshot is not the default.

>> handles config.h-vms.template (why is there a prefix
>> with sys$disk:[]?) and the NFS/ODS-2 variant of that:
>> CONFIG.H-VMS$5NTEMPLATE.
> 
> The prefix of sys$disk:[] is used in many existing places.  One of the
> things that it helps is bulding with the default on a search list.
> ...

Maybe it is too late, here. I don't see the difference in accessing the
file with sys$disk:[]config.h-vms or config.h-vms.

>>> I had to modify the pipe command to fit the command line length
>>> restrictions of VAX/VMS 7.3.  EDT is not one of the utilities that has a
>>> problem reading from NFS files.

With the sys$disk:[]-prefix, the command token for the pipe command gets
bigger. The token is the restriction, the command line itself can be longer.

Using the result of the f$search for the templates makes this command
even longer, as the full VMS file spec is returned. And then the pipe
can break depending on the current environment: how deep in a directory
tree the file is found, that is, where the default directory is.
Therefore I suggested to f$parse the name, after the file is found.

>> Now there is a f$$search in makefile.vms. I don't think it is a problem
>> when the files aren't there, the "-" can handle this. What is the reason
>> to check with extra DCL commands whether the files are present, the
>> "ignored" make error? (And then there is no need for the '-" any more.)
>> What kind of problem should this solve?
> 
> It gets rid of the error messages written to SYS$OUTPUT.  The '-' can be
> removed.  I did not do it on this latest patch.

These are usual error messages when the files are not present and the
ignore prefix takes care of that. Anybody using make is probably aware
of that.

> Yes, as I have found many issues in other projects where serious real
> errors and warnings were ignored because there were so many other
> warnings and errors that were apparently harmless.

I don't think this applies here. But for whatever it is good, I changed
makefile.com to place the objects in the same directory as the source,
the place where the makefile.vms expects them.

> And a clean target needs to deal with aborted build, so should not
> generate error messages when the target directory is already clean.

In my opinion, with an aborted build, most people will expect to see
such messages from make.

Again, appended is what I suggest to change, to make a version for
VAX/VMS, including the helper to prepare a build from the snapshot -
with the template patterns - plus the above mentioned change for objects
in the makefile.com.

gnu-make-vms.patch
Description: Text Data