[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: h.becker
Subject: Re: VAX/VMS 7.3 and build from copy of master.
Date: Mon, 24 Feb 2014 22:03:41 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130519 Icedove/17.0.5

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?

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

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? 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.

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

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?

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?

reply via email to

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