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

[h.becker]

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:

>> Sorry, I don't understand what is menat with "VMS currently does not do
>> shell expansion of exported symbols." Any example?
> 
> I can not put "''foobar'" in a recipe where foobar is an exported
> symbol.  While DCL is not technically a shell, in the context of make it
> is easiest to consider it a shell.

As far as I know, this is called 'forced symbol substitution'. I think
it was discussed earlier, that this kind of symbol substitution isn't
done, when lib$spawn is used with a single (DCL) command. I concluded
that it is done when reading the (DCL) commands from an input source.
That's why I suggest to switch to ALWAYS use command procedures. As
pointed out, it makes the code changes smaller/simpler and it gives the
forced symbol substitution for free.

> I am more inclined to try to avoid generating the VMS command procedure
> where ever possible at this time.  For one thing, it does not handle the
> case for built-ins.  And it may be desired to create more built-ins such
> as handling library creation more efficiently.

I agree, that built-ins can't be used with command procedures (and as
far as I understand they can't be used with ONESHELL either). Command
procedures are used today, as I mentioned and it seems that they work.

>From what I see, creation of libraries isn't done so often. For some
software projects it may be done only once.

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

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

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