[Top][All Lists]

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

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

From: John E. Malmberg
Subject: Re: VAX/VMS 7.3 and build from copy of master.
Date: Wed, 26 Feb 2014 01:07:42 -0600
User-agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3

On 2/25/2014 5:45 PM, h.becker wrote:
On 02/25/2014 01:36 AM, John E. Malmberg wrote:

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.

Default of non-default has nothing to do with it. Not having the makefile run the prepare_vms.com if needed just makes more work for me every time I have to rebuild the world.

I have removed it, because we need to move on.

I do not see why building from master should take more manual steps than building from a release tarball. It is just more work for the programmer.

I will just create a local single command file that runs everything for now.

handles config.h-vms.template (why is there a prefix
with sys$disk:[]?) and the NFS/ODS-2 variant of that:

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.

It is an issue on search lists, in some cases if the sys$disk:[] is missing, the file may not get found due to the stickyness of DCL file handling. I may be putting in a few more places than absolutely needed just as a defensive measure.

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.

I have put that in, but formatted it to fit 80 column lines.

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.

I would not count on 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.

I think it is sloppy to have error messages for expected conditions.


Attachment: 0001-Build-from-Master-and-VAX-VMS-7.3-revision-3.patch.gz
Description: application/gzip

reply via email to

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