> From: Paul Smith <[EMAIL PROTECTED]> > Cc: make-w32@gnu.org > Date: Wed, 10 Oct 2007 09:17:11 -0400 > > Hi Eli; I was reviewing this patch: > > http://www.mail-archive.com/make-w32%40gnu.org/msg01387.html > > and I had a few questions: first, I tried this with UNIX make (using the > warning in the SHELL variable) and it already works there; I'm not sure > why the windows port is different in this respect?
The Windows port is different because it does not blindly obey the value of SHELL: it knows about cmd.exe, the stock Windows shell and about Unixy shells whose names include the substring "sh". Any other value of SHELL is required to be an existing file, specified either as an absolute file name, or as a relative file name that can be found along PATH. See the function find_and_set_default_shell, which is specific to Windows, for the gory details. If the value of SHELL fails the tests of that function, that value will be rejected. > Second, I don't quite get how this works; it seems to me that you're > expanding the value when the variable is defined (where things like $@ > etc. are not set yet) and then storing the expanded variable...? Yes, that's true. But I think that things like $@ will get evaluated when the command $(SHELL) -c whatever is run by Make, because at that time all the variables present in the command line are expanded, right? > Third, I think you have a memory leak; you're not freeing the > (potential) contents of alloc_value before you reassign it. Yep, my bad. Sorry. _______________________________________________ Make-w32 mailing list Make-w32@gnu.org http://lists.gnu.org/mailman/listinfo/make-w32