On 21 April 2007 10:02, Eli Zaretskii wrote: [ got left sitting in my drafts folder over the weekend. ]
>> From: "Dave Korn" >> Date: Fri, 20 Apr 2007 17:18:01 +0100 >> On 20 April 2007 17:15, Aaron Shatters wrote: >> >>> As I noted previously, there are many workarounds to this problem. I am >>> interested in fixing the root cause. After all of this investigation, do >>> we have consensus that this is a limitation of make? More importantly, do >>> we have consensus that it should be fixed? We seem to have run out of >>> reasons for not fixing this problem. >> >> Since "echo." is clearly a shell builtin, and since the code is supposed >> to recognize shell builtins and hand them off to the shell, I would support >> fixing this in the source. > > I don't think "echo." is a shell builtin. It is a peculiar feature of > the cmd.exe command parser. This is a semantic quibble. The shell builtin is "echo", "echo." is an alternative form, and the main point is: On 21 April 2007 10:00, Eli Zaretskii wrote: >> Date: Fri, 20 Apr 2007 09:14:31 -0700 (PDT) >> From: Aaron Shatters >> >> As I noted previously, there are many workarounds to this problem. I am >> interested in fixing the root cause. After all of this investigation, do >> we have consensus that this is a limitation of make? More importantly, do >> we have consensus that it should be fixed? We seem to have run out of >> reasons for not fixing this problem. > > No, I don't agree that this is a limitation of Make. Make just > invokes the shell built-in, and the shell built-in behaves like it > does from the command line. Actually, if we're talking about "echo.", make *fails* to invoke the shell builtin, and ends up invoking an executable of the same name that's on the path. cheers, DaveK -- Can't think of a witty .sigline today.... _______________________________________________ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32