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
[email protected]
http://lists.gnu.org/mailman/listinfo/make-w32
