At Thu, 06 Mar 2025 06:02:47 +0700, Robert Elz <kre%munnari.OZ.AU@localhost> wrote:
Subject: Re: parallel build failure with .c.o rule interrupted mid-step!
>
>
> It certainly isn't undocumented, from man sh ...
Ah, yes, sorry -- I meant to remove that part of the comment about -q --
I'm not quite sure why I had trouble finding the reference the first
time around.
> So assuming by "hiding what is being read" you mean that
> one or both of the -v and -x options get ignored while startup files
> (.profile and $ENV) are being read, then use.
Yes, I think of -v as showing what the shell has read, which is
basically true in how it works if I understand correctly, and of course
-x shows what it is about to execute.
In working on this test makefile I quickly found my $ENV had a really
big comment before the test where it was deciding it wasn't interactive
and so make was showing that whole big comment over and over again!
> It is something of a
> bizarre option, which has weird consequences, that I am unable to properly
> work around (or never have been) but in your average simple case, works
> just as documented (where it gets weird is when one of those files wants
> to alter the state of -v or -x).
Hmmmm.... that's exactly what can happen if you set up make with .SHELL
to work more like a POSIX shell with full error and echo control, etc.
E.g. if there are commands with '-' or '@' flags on a make rule.
> -s means
> reading stdin, which a sh run from make should never be doing, or I
> wouldn't have thought so anyway.
If I remember correctly /bin/sh adds 's' to $- when it is reading a
script file from stdin, which is, I believe, exactly what make is
normally doing (here it is set up in the job's child process):
if (dup2(fileno(job->cmdFILE), STDIN_FILENO) == -1)
execDie("dup2", "job->cmdFILE");
(where cmdFILE was opened on the temporary file to where the job
commands are written -- that file is unlinked while still open)
Hmmmm.... maybe there's a clue to this problem in the fact the child
shell's output is to a pipe which must be read by make. Maybe they get
closed too soon?
I have been meaning to mention that I often see long-running c++
commands when a build encounters an error in some other parallel branch,
but I don't think I see the associated make or shell processes. I
thought that should have been fixed with Roland's initial change, but
perhaps the handling of the output pipes still isn't right?
--
Greg A. Woods <gwoods%acm.org@localhost>
Kelowna, BC +1 250 762-7675 RoboHack <woods%robohack.ca@localhost>
Planix, Inc. <woods%planix.com@localhost> Avoncote Farms <woods%avoncote.ca@localhost>
Attachment:
pgpgEQvKtMK9W.pgp
Description: OpenPGP Digital Signature