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
> 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
"Erich Boleyn wrote:"
With a Bourne style shell you can pass what you want to the environment
as done below.
>
> Summary:
> Environment variables set in the Makefile do not get inherited
> into anything run via the "shell" subcommand.
>
> Tested on GNU Make versions:
> 3.81 (o
On Tue, 2015-02-10 at 10:35 -0800, Erich Boleyn wrote:
> Summary:
> Environment variables set in the Makefile do not get inherited
> into anything run via the "shell" subcommand.
Yes, this is known:
https://savannah.gnu.org/bugs/index.php?35323
_
This looks like an instance of bug #775:
https://savannah.gnu.org/bugs/?func=detailbug&bug_id=775&group_id=71
--
---
Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at:
http://www.gnu.org
Paul:
Thank you very much. I will try 3.79.1 to see what happens. Wind River
Systems technical support engineer is using 3.79 and it seems to resolve
the problem.
- Abe
"Paul D. Smith" wrote:
> GNU make does support Windows, but not at version 3.74.
>
> Support for Windows was not added until
GNU make does support Windows, but not at version 3.74.
Support for Windows was not added until version 3.75.
If you have a version of GNU make for 3.74 on Windows it must be part of
the Cygnus package: that version of GNU make is slightly different than
the standard GNU version and you need to
18 matches
Mail list logo
