[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug #42447] Fix exporting symbols for recursive make on VMS.
From: |
John E. Malmberg |
Subject: |
Re: [bug #42447] Fix exporting symbols for recursive make on VMS. |
Date: |
Sat, 21 Jun 2014 17:36:30 -0500 |
User-agent: |
Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 |
On 6/20/2014 7:59 AM, h.becker wrote:
On 06/14/2014 07:14 PM, John E. Malmberg wrote:
About command line length:
I think I understand. So it would be a compile time option for
Alpha/I64. Or do you really have VAX/VMS 8.3?
A typo. VAX/VMS stopped at 7.3
I know of 8.2 but never saw 8.3.
I left VMS Engineering just after VMS 8.3 got shipped. There were
significant fixes to the CRTL for Unix compatibility.
Again, me thinks, letting make
> always generate command procedures is a much simpler approach
> with less code changes.
We can potentially add that as a mode later, but right now I want to
implement it this way, after we get all the tests passing, then we can
look at making other changes.
It looks like there will be a lot of incremental changes to get all the
test working and get symbolic links and dynamic loaded modules working.
So I now want to get this set of changes committed so that we do not end
up with a large set of changes that will be hard for anyone to review or
follow.
Then DCL has to read from the mailbox and then all the symbol
substitutions should work. To me this looks more like a ONESHELL
implementation.
It is a ONESHELL implementation.
Yes, even for a single action, one can replace the file based command
procedures with mailbox based command procedures. To me using mailboxes
seems to be a bigger change. With fast disks and cached files it may not
be worth the effort. But what do I know who uses old systems, anyway.
My DS-10 has slow disks (IDE), and I am using NFS served disks for
source files.
Mailboxes will be a bigger change, but they have the potential for the
greatest speedup.
Regards,
-John