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 to
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 mor
From: 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
> 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
> Davi
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 u
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
bei
=\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 to
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 I do
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 rel
egi
Sent: Thursday, March 17, 2022 08:59
To: bug-make@gnu.org
Subject: GNU Make bug report: broken dry-run functionality with sub-make
invocations
* EXTERNAL EMAIL *
Dear Devs,
I stumbled upon a rather rare case where Make produces a false error with the
--dry-run switch. I’ve attac
Dear Devs,
I stumbled upon a rather rare case where Make produces a false error with the
--dry-run switch. I've attached a sample Makefile for reproduction.
The output of make main_target with this file is the following:
$ make main_target
mkdir logs
make external_target | tee logs/external_task.
I'm sorry, but first you're using Cygnus GNU make which is not identical
to the standard GNU make provided by the GNU project; you need to direct
your problem to Cygnus/Red Hat.
Second, unfortunately we don't have the resources at GNU to handle
Windows-specific issues; certainly we can't do anyth
Hello.I found a bug. (I think it may be a bug.)I use Cygnus make.exe on MS Window 2000.Dumping stack errors have occured in my PC.So, I'd like to report the error statusWhen you succeed solving the problem, reply with a mail to explain how to fix it, please...Have a good day...Bye...OS: MS Wind
16 matches
Mail list logo
