At Sat, 6 Mar 2010 08:51:20 +0000, David Holland
<dholland-current%netbsd.org@localhost> wrote:
Subject: Re: [ANALYSED] kernel object compilation failure unnoticed ?
>
> Not really. Once you remember that each separate line is passed as a
> unit to sh -c, the rest follows from how the shell works.
Except as you show below that's not always the case, and also "line" has
to be very carefully defined, as it doesn't mean the same thing to the
shell as it does to Make, and worse the "trivial" inclusion of some
backslashes change everything. It breaks some principles of least
surprise, IMO, and always has.
> The real complication is that in make -j mode, our make doesn't do
> that but instead feeds stuff in blobs to the shell's stdin, so the
> effects of operations like cd persist longer than one expects.
>
> This behavior is definitely questionable...
Well, except that's the along the lines of behaviour I was trying to
describe, one which might actually try to meet at least some principles
of least surprise.
Perhaps every make "rule" should be treated as a stand-alone script,
whether it's one line or multiple "lines", and as such each should be
executed by a unique shell instance.
Other Make-like tools do this. For example Jam expands the entire
"action block" for a rule into a string of text that's passed as the
single parameter to "sh -c". Cook goes a step further and can generate
an entire canonical shell script that can be run with one (initial)
shell invocation, and apparently it can also manage multiple parallel
threads of execution while still handling rules which must be
single-threaded (and with some helpers it can run jobs on other hosts,
even with a trivial form of load balancing).
Of course both Cook and Jam scoff at the very idea of recursive make. :-)
> I suspect that's because historically sh doesn't do tilde-expansion.
> If we're committed to doing so we should teach make accordingly.
I was trying to say that if Make didn't try to optimise execution by
trying to figure out if shell parsing was needed or not, then it
actually wouldn't have to know anything at all about shell syntax.
--
Greg A. Woods
Planix, Inc.
<woods%planix.com@localhost> +1 416 218 0099 http://www.planix.com/
Attachment:
pgpxDQKCDMXsH.pgp
Description: PGP signature