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

[John E. Malmberg]

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
> > > > tarballs.
> >
> > 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:
> 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.

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.

Regards,
-John

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