[Top][All Lists]

[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, 14 Jun 2014 12:14:22 -0500
User-agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3

On 6/6/2014 10:19 AM, h.becker wrote:
On 06/06/2014 05:44 AM, John E. Malmberg wrote:
On 6/1/2014 3:22 PM, h.becker wrote:
On 05/28/2014 07:00 AM, John Malmberg wrote:

And the pipe command may allow implementing I/O redirection with out a
command procedure if the lines are short enough.

As I documented somewhere, I/O redirection is not really something make
has to do. But it was already there, when I looked at the sources.
Whether VMS pipe commands are the right solution for I/O redirection is
another question: I don't see that the pipe command supports appending
output. And I guess that pipe commands tend to be longer than simple

The make self tests are expecting recipes to redirect output, so it is useful to have for VMS.

And someone needed in a VMS specific makefile to add it.

I think there is a way to use pipe commands to do appending of output.
I may have even used it in the patches for the make tests. By moving the code into the vmsjobs.c or equivalent, it can remove VMS specific changes from the self tests. I have to do some tests.

Right now, my focus is on getting all the tests to pass.

The current code appears to be always using the older limitation on the
command size when determining when to switch to command files, instead
of basing it on the version of VMS used for the compile.

"for the compile"? Maybe I have a language problem, but I think it
depends on the VMS version/environment where Gnu make runs.

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.

For exported symbol substitution, I would prefer it to be done when the
command to be sent to the child process is created.

Does that mean re-implementing in make what DCL can do? As with I/O
redirection, I don't think this is something make should do. Also, I'm
not sure if that's what a user expects. For example, f$time(0) may be
slightly off and f$getjpi(0,"pid") is simply wrong.

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.

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.


reply via email to

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