[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: Mon, 24 Feb 2014 18:36:49 -0600
User-agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3

On 2/24/2014 3:03 PM, h.becker wrote:
On 02/24/2014 03:10 AM, John E. Malmberg wrote:
On 2/22/2014 7:03 AM, h.becker wrote:
On 02/22/2014 01:19 AM, John E. Malmberg wrote:
What I am proposing:

1. Rename config.h-vms.template to be config-h-vms.template (or similar)
so that it is the same on all VMS volumes.  Include this in the release

Renaming the template file is not that easy as it is included in a list
rule in mainMakefile.  A significant rewrite would be needed.

I didn't look at maintMakefile, maybe I should have done before
suggesting a change in the name. There is

$ make -nf maintMakefile config.h-vms
rm -f config.h-vms
sed -e 'address@hidden@@g' \
             -e 'address@hidden@@g' \
           config.h-vms.template > config.h-vms
chmod a-w config.h-vms

Which with config-h-vms in TEMPLATES would become a
rm -f config-h-vms
sed -e 'address@hidden@@g' \
             -e 'address@hidden@@g' \
           config-h-vms.template > config-h-vms
chmod a-w config-h-vms

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.

I do not know if Paul is following this thread, as a rename of the file would need to be tested with their other procedures.

Therefore I have the prepare_vms.com handle both the ODS-5 (normal
version) and the NFS mangled format for ODS-2 volumes.

The prepare_vms.com (is still invoked in makefile.com, which I still
don't understand)

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.

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.

I have a search list of prj_root = lcl_root:,vms_root:,src_root: where all changes by the build scripts get written into lcl_root:

lcl_root: is specific to the system that the build is on.

vms_root: and src_root: are common to all the build systems.

vms_root: is work in progress changes

src_root: is pointed either at a checkout of master or an unpacked release tarball as needed.

When I unpack a snapshot on an ODS-2 disk from a tar archive (with
vmstar) I get CONFIG.H-VMS_TEMPLATE and from a zip archive I get
CONFIG_H-VMS.TEMPLATE. Why is NFS preferred over the other two variants?

Because I do not use vmstar, or was aware that anyone else was in this case, so I only added in the variants that I needed.

When there is special code for one file name variant I don't see why
there shouldn't be special code for the other ones - or none at all.

Then I can add in the code for the existing vmstar variant.

Again, there is no problem with the current released tarball, which
contains a file which is named either config.h-vms or CONFIG.H-VMS on
the VMS disks.

Are there other file name variants, which I don't know?

Pathworks V5/older and some SAMBA -> CONFIG.H-VMS__2ETEMPLATE

Pathworks V6+ and newer SAMBA -> CONFIG_2EH-VMS.TEMPLATE

Some older SAMBA variants will invert case when a $ is in the filename just like NFS does. Does not apply in this case.

I would like to see vmstar enhanced to know about these filename encodings.

So far, the best one could do is to f$search for
> "config*vms.template" and "config*.*vms*template". I'm still not
> convinced that this should be there at all but that could be a
> compromise or a catch-almost-all/catch-more variant.

Two f$search templates appear to be able to find all of the above encodings. I have update the prepare_vms.com procedure.

2. Put a #include <types.h> near the start of config-h-vms.template so
that __CRTL_VER is properly defined.

Done.  No other formatting done to the file at this time.

3. Have a procedure that converts the config-h-vms.template to config.h.
   Since the information needed for this is in the configure.ac file.

I agree to have this for builds from a snapshot.

prepare_vms.com just makes that config.h_vms file.

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 reading from configure.ac it seems, the labels news_read_loop*
should change as well.

I missed that.  Changing to ac_read_loop/ac_read_loop_end

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.

On the other hand, I never paid attention to change makefile.com to
compile the [.glob]-sources to [.glob]-objects. That would make some
"cannot remove" message go away, but is it (and the other ones) worth
the change?

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.

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


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

reply via email to

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