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

[h.becker]

On 02/21/2014 03:50 AM, John E. Malmberg wrote:
> On 2/20/2014 9:52 AM, h.becker wrote:
> 
>> 1. building from a git-cloned repository
>>
>> config_h_from_vms_template.com is a rather long name, no problem.
>> However, there seems to be something similar for w32: "Windows32 SCM
>> build preparation of ...". That file is named prepare_w32.bat. So I
>> suggest to rename config_h_from_vms_template.com to prepare_vms.com. OK,
>> the lowercase vms/w32 is not consistent with other file names which have
>> VMS/W32, if that is important ...
> 
> Ironically the file case is significant if you are serving files via NFS
> to VAX/VMS.  When doing that, only lower case filenames show up
> correctly on the VAX.  The rest get NFS mangled.

... which seems to be a feature of a NFS-client on/for VMS/ODS-2.

> 
> I am ok with prepare_vms.com but prefer a name that describes the
> function, since a prepare_vms.com could mean doing many things, and this
> is a specialized command procedure.

As prepare_w32.bat, I don't expect the new "prepare_vms.com" to show up
in the released version of make, so it is an "internal" command
procedure to prepare a VMS build based on a snapshot of the repository.
It's a suggestion and it seems to match a similar file for w32.

>> Whether it is useful to check for NFS/ODS-2 encoded filenames, I don't
>> know. But then, when a git clone is copied to an ODS-2 disk, somehow,
>> how would one handle filenames with multiple dots, anyway. I suggest to
>> simply require an ODS-5 disk for git cloned repositories and leave it to
>> the user of old VMS systems to handle problems on other disks.
> 
> As I stated above, I am using a common NFS served disk for all my
> systems.  So for me to build on VAX, I have to deal with the NFS mangled
> names.

Isn't that what I said: you have to deal with it? :-) Again, this is
only needed for the snapshot builds. To me it seems enough to either let
the user edit the prepare_vms file and change the symbol assignment for
config_template or to provide a P1 parameter.

Btw. are all NFS clients for VAX/VMS doing the identical file name mapping?

> 
> How a clone shows up on ODS-2 depends on what tool was used to unpack it.
> 

This seems to indicate that handling all of the possible file names for
config.h-vms.template is even more work.

What about a simple solution changing the template file name to
config.h-vms-template (or config-h-vms.template)? That would be more or
less the same file name  across all VMS platforms, ODS-x disks and NFS
served disks. But this requires a change in the kit build, which would
be a small one. However I have to admit, I don't know how a kit build is
done.

>> The user
>> can change the symbol config_template, anyway. Maybe a comment should
>> explain this, or maybe a P1 can be added so that a user can supply an
>> ODS-2 name. To me it seems removing these special filenames makes things
>> simpler. And, to make generating the config.h-vms more obvious I would
>> use some "replace" commands. Again, I use a "new" feature: pipe, here to
>> avoid creating a temporary file.
> 
> Some VMS utilities do not play well with random accessing files on an
> NFS volume, particularly before VMS 8.4.  So I use a more restricted set
> for building.  I did not create any temporary files in my scripts.
> 

I don't understand your comment on NFS files and VMS utilities. A
temporary file would go to SYS$SCRATCH, or? Anyway, I suggested to make
it more obvious what is replaced. The script with reading the file and
processing it line by line is less obvious to me, maybe because the to
be replaced tokens didn't show.

My opinion here is that just for NFS-problems and only for building from
a snapshot it isn't worth to add complexity to the scripts. Agreed, the
pipe command isn't simple, either.

How far in VMS versions do you want to go back that there is no pipe
command available?

>> Whether invoking this command procedure should go into makefile.com is
>> another question. I think it isn't necessary. The prepare_w32.bat isn't
>> run from any other .bat-file, as far as I can see.
> 
> I think it should go there, then we have the same build procedure on
> master as in a release tarball.  Eventually I hope to get to a single
> command file that will do the complete build and create a PCSI kit with
> no extra editing.

I think it shouldn't go there. As said above, I don't expect the file to
show in the released kit.

>> 2. Compiling and linking guile
>>
>> Yes, after the release of 4.0 there was a change which added a call to
>> guile_gmake_setup to main.c. I sent a patch to handle that for VMS, in
>> last November. Obviously it didn't make it into the repository.
>>
>> But I don't see that you need gmk-default.h without having HAVE_GUILE
>> defined.
>>
>> To me it seems enough to change makefile.com and makefile.vms as in the
>> appended diff/patch and then there is no need for gmk_default_h.com.
> 
> I am not sure yet what the guile module can do on VMS, so I would prefer
> to leave generating the header file in place until that is determined.

My opinion is to leave it out as long as it isn't really used. When it
is used it can be added any time. Also, as far as I can see,
gmk-default.h is in the released kit. And it seems OS independent. So
there seems to be no need to build it in makefile.vms.

>> 3. Changes in config.h-vms.template
>>
>> Isn't it more obvious to do what decc$types.h does?
>> #ifndef __CRTL_VER
>> # define __CRTL_VER __VMS_VER
>> #endif
> 
> It is also not a good idea.  The double underscore macros should only be
> redefined as a last resort.  Doing the above hack will also unexpectedly
> impact people doing cross version builds.

So you think including a VMS/DECC supplied include file like
decc$types.h would not be a good idea? As far as I can see, that hack is
in the latest version of that include file as well.

This is a VMS specific file and it should be safe to include
decc$types.h. So far I didn't try, but that would move the hack to a
supported place. Except, you want to have this building for VAXC as
well. Do you?

> Are you subscribed to bugs-make or equivalent, or do you want me to
> continue to bcc you?

Yes, I'm subscribed to bugs-make.