bug-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #30714] List of shell commands is outdated/Fallback to shell


From: Eli Zaretskii
Subject: [bug #30714] List of shell commands is outdated/Fallback to shell
Date: Wed, 11 Aug 2010 17:39:19 +0000
User-agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 1.1.4322)

Follow-up Comment #10, bug #30714 (project make):

"It depends on what you consider "normal". It's normal for CreateProcess, of
course, but this is not how make should work. I don't see any reason why
Windows version should behave differently than Unix version, and I believe
that Unix version does not look for a command in the directory where 'make'
is
installed in the first place."

Again, it's normal on Windows.  Every Windows program that invokes subsidiary
programs behaves like that.  Make is working like that for a long time, so any
serious changes are likely to cause trouble somewhere.

"As for shell's command line limit: it doesn't really matter, since this is
the shell's limitation and the Makefile maintainer should be aware of limits
of the selected shell."

It doesn't help "to be aware" when the command length exceeds the limits. 
There's no easy escape, sometimes no escape at all.

"It's wrong, because it doesn't work the way it is supposed to work. 'make'
claims to support custom shell selection by setting $(SHELL), but its value is
ignored."

That's a different bug report, let's not mix them.  That other bug will be
fixed when I have time to work on it.  Here we are talking about SHELL whose
value is one of the two shells that Make on Windows pretends to know
intimately, like the Unix version does with /bin/sh.  For that use-case, I
think Make on Windows behaves like the Unix version does: if the command
fails, Make does not try to run it via the shell.

Anyway, I think it's time to wrap this up.  Let me say in conclusion that I
think Make works reasonably well on Windows, even though it might not be 100%
clean in some cases.  OTOH, it supports 2 standard shells (sh.exe an cmd.exe)
while the Unix build supports only one, so some rough corners are inevitable. 
It took some non-trivial effort to get where we are now.  Given the feeble
resources I'm able to devote to maintaining the Windows build, I cannot even
review patches that make revolutionary changes in job.c and be responsible for
 their effect on Make, let alone do it myself.  So any serious surgery in how
Make invokes programs today will only happen if someone else will take over
the maintenance of the Windows port.  FWIW, I will happily relinquish that
responsibility to a willing volunteer.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?30714>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]