Re: [bug #42447] Fix exporting symbols for recursive make on VMS.

[h.becker]

On 06/14/2014 07:14 PM, John E. Malmberg wrote:

> I think there is a way to use pipe commands to do appending of output.

I don't know of any way to have that in the current pipe command I tried
(V8.3/Alpha). The only workaround seems to use append/new, but that has
some incompatibilities/limitations with piped output:

$ pipe show time
  20-JUN-2014 08:24:03
$ pipe show time >x.x
$ ty x.x
  20-JUN-2014 08:24:15
$ pipe show time | append/new sys$pipe x.x
$ ty x.x
  20-JUN-2014 08:24:24
$ pipe show time | append/new sys$pipe x.x
$ ty x.x
  20-JUN-2014 08:24:24  20-JUN-2014 08:24:29
$ dump/rec x.x
...
Record number 1 (00000001), 22 (0016) bytes, RFA(0001,0000,0000)

 38302034 3130322D 4E554A2D 30322020   20-JUN-2014 08 000000
                       3531 3A34323A :24:15.......... 000010

Record number 2 (00000002), 22 (0016) bytes, RFA(0001,0000,001A)

 38302034 3130322D 4E554A2D 30322020   20-JUN-2014 08 000000
                       3432 3A34323A :24:24.......... 000010

Record number 3 (00000003), 22 (0016) bytes, RFA(0001,0000,0034)

 38302034 3130322D 4E554A2D 30322020   20-JUN-2014 08 000000
                       3932 3A34323A :24:29.......... 000010
$

> A program built on a version of VMS that does not support the longer
> command lines would not be able to see the compile time symbols that the
> support was present on, so while it could build the support in, the code
> would look different.
> 
> A program built on a version of VMS that supports the longer command
> lines would not be able to run on the older versions of VMS, unless
> special (and mostly undocumented) build procedures are used.
> 
> And then you need the older version of VMS to validate that the build
> works.  Currently I am limited to VAX/VMS 8.3, Alpha 8.3/8.4, and
> Itanium 8.4.
> 
> So that is why I consider it a compile time option.

I think I understand. So it would be a compile time option for
Alpha/I64. Or do you really have VAX/VMS 8.3? I know of 8.2 but never
saw 8.3. Again, me thinks, letting make always generate command
procedures is a much simpler approach with less code changes.

> Lexical functions work in recipe commands now.  Symbol substitution does
> not.  I am just looking at simulating $xxx expansion at this point, done
> before the command is run.  GNU make is already supporting other bits of
> shell simulation on VMS, so the precedent of doing this type of thing
> has already been set.

As mentioned before, forced symbol substitution doesn't work with
(lib$)spawn passing a single command, any other symbol substitution
works. That includes forced symbol substitution with lexical functions,
which in this case don't work, as it is a forced symbol substitution.
With using command procedures for actions all symbol substitutions work.

> I also plan to look at having a pool of subprocesses and sending
> commands to them over mailboxes instead of spawning a new process for
> each line of a recipe.  This should speed make, particularly on the
> older systems.

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.

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.