Ambrus Sumegi (21 March 2022 14:22) wrote:
> If the invocation is a function, i.e., `$(make,"external_target") |
> tee logs/external_task.log` then Make knows exactly where the call to
> the sub-make ends without having to parse a shell command. So, when
> running with the -n switch, it can simply
rget | tee logs/external_task.log"
and proceed to show the output of `make external_target -n`
-Original Message-
From: Paul Smith
Sent: 21 March 2022 14:18
To: Ambrus Sumegi ; bug-make@gnu.org
Subject: Re: GNU Make bug report: broken dry-run functionality with sub-make
invocations
On Mon,
(We generally prefer to use inline replies on the GNU lists, rather
than top-posted replies, thanks)
On Mon, 2022-03-21 at 13:22 +, Ambrus Sumegi wrote:
> If the invocation is a function, i.e., `$(make,"external_target") |
> tee logs/external_task.log` then Make knows exactly where the call
On Mon, 2022-03-21 at 09:34 +, Ambrus Sumegi wrote:
> For the record, I’ve thought of a sort-of-solution to the “would you
> have Make parse the shell command” question over the weekend. If the
> sub-make was called through a function rather than a variable, the
> whole issue could be a lot
m: Martin Dorey
Sent: 17 March 2022 19:27
To: Ambrus Sumegi ; bug-make@gnu.org
Subject: Re: GNU Make bug report: broken dry-run functionality with sub-make
invocations
> the statement after the pipe also gets executed
Would you have Make parse the shell command, assuming that SHELL isn't eg
> On Mar 18, 2022, at 2:03 PM, Paul Smith wrote:
>
> On Fri, 2022-03-18 at 17:48 +, Martin Dorey wrote:
>> Maybe putting it in the form of a patch on the latest git source will
>> help it over the finish line:
>
> I'm OK with adding some short text about this into the man page. As
>
Paul Smith wrote:
I'm OK with adding some short text about this into the man page. As
David mentions it may be important enough to do that since command
being run by make even when the user gives "-n" could give unexpected
or even unpleasant consequences.
The most unpleasant consequences of
On Fri, 2022-03-18 at 17:48 +, Martin Dorey wrote:
> Maybe putting it in the form of a patch on the latest git source will
> help it over the finish line:
I'm OK with adding some short text about this into the man page. As
David mentions it may be important enough to do that since command
=\fIfile\fR
Do not remake the file
From: David A. Wheeler
Sent: Friday, March 18, 2022 09:08
To: Ambrus Sumegi
Cc: psm...@gnu.org ; Martin Dorey
; bug-make@gnu.org
Subject: Re: GNU Make bug report: broken dry-run functionality with sub-make
invocations
> On Mar 18, 2022, at 3:19 AM, Ambrus Sumegi wrote:
>
> Thanks a lot for your suggestions, Martin and Paul. I understand the
> reasoning behind why Make cannot improve this behavior, and the conditional
> execution of tee that you both proposed looks like a concise and elegant
> solution
022 20:08
To: Ambrus Sumegi
Cc: bug-make@gnu.org
Subject: Re: GNU Make bug report: broken dry-run functionality with sub-make
invocations
On Thu, 2022-03-17 at 18:27 +, Martin Dorey wrote:
> That coped with -nj --no-print-directory on the one version of Make
> that I tested it with, but
On Thu, 2022-03-17 at 18:27 +, Martin Dorey wrote:
> That coped with -nj --no-print-directory on the one version of Make
> that I tested it with, but I don't know how portable that would
> prove.
Modern versions of make guarantee a canonical format of MAKEFLAGS such
that you can parse them
> the statement after the pipe also gets executed
Would you have Make parse the shell command, assuming that SHELL isn't eg
/usr/bin/perl, splitting off anything after | and maybe ; and && and, why not,
||, so it only dry-runs the part of the command that invoked $(MAKE)? The
current behavior
13 matches
Mail list logo
