> Date: Mon, 23 Apr 2007 07:20:53 -0700 (PDT) > From: Aaron Shatters <[EMAIL PROTECTED]> > Cc: [email protected] > > >I remain unconvinced that we should ``fix'' this just because this > >fundamental incompatibility between shells sometimes causes trouble in > >Makefiles that assume Posix `echo' where it isn't guaranteed to exist. > > The problem is that Make is *not* invoking the shell built-in
I was talking about the situation where `echo' is called with an empty command line. In that case, the shell does get called. As for the "echo." case, it's just a bizarre consequence of cmd command-line parsing (there are many more manifestations of that, and others have pointed out some of them). I don't think there's a very large demand for supporting that in Make, and even if there is, I don't plan on working on that any time soon. > I am confused as to what level of support Make is trying to achieve. There > are !unixy_shell conditions and dos cmd references all over the code. What > are the purposes of these if not to handle "fundamental incompatibilities > between shells". I don't understand where the point of disagreement is. I > understand that this is not a bug in Make, but, in my opinion, this is a > perfectly reasonable enhancement. Make knows about the existence of the > windows shell 'cmd.exe'. It knows what the shell built-ins are, and it > already handles this shell specially (for example, sh_cmds_dos in job.c). > What reasoning is there for excluding this functionality, when all of the > other specifics associated with this shell are handled? My reasoning is that supporting such weirdo parsing is a maintenance burden. The way Make parses the commands now cannot be easily modified to cater to these strange corners in cmd. You can always say `cmd /c "echo."', or use some special character, such as redirection or pipe, if you need to force Make to call the shell. _______________________________________________ Make-w32 mailing list [email protected] http://lists.gnu.org/mailman/listinfo/make-w32
