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. _______________________________________________ Bug-make mailing list Bug-make@gnu.org https://lists.gnu.org/mailman/listinfo/bug-make
