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.
"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
_
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 (on Ubuntu)
4.1 (on FreeBSD)
Example Makefile contents which can show the bug:
export FOO=foo
mai
%% David Buehler <[EMAIL PROTECTED]> writes:
db> I'm expecting this makefile to echo "mylib", but it echos
db> "Makefile" then "mylib"... perhaps there's something esoteric
db> going on that I haven't figured out from the documentation.
The latter :).
Check the GNU make manual section "How
I'm expecting this makefile to echo "mylib", but it echos "Makefile" then
"mylib"... perhaps there's something esoteric going on that I haven't
figured out from the documentation.
Running on Debian GNU/Linux Stable. I installed make version 3.80 just to
check that the behavior is the same as 3.79
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
On a Pentium 4, using Windows 2000 (service pack 3) and cygwin.
-
$ uname -a
CYGWIN_NT-5.0 ALPHA 1.3.17(0.67/3/2) 2002-11-27 18:54 i686 unknown
-
$ make -v
GNU Mak
%% Tim Noell <[EMAIL PROTECTED]> writes:
tn> Attached please find gnumakebug.tar.gz, containing my minimum
tn> example.
Offhand I'd prefer the files to be attached outside of a compressed tar
file, unless they're large; it's much simpler to read them in your email
than it is to save off the
Hi GNU Make Team:
I have encountered a situation with GNU Make that doesn't seem right. It could
be something simple that I am overlooking, but wanted to forward the example so
you folks could check it out.
Attached please find gnumakebug.tar.gz, containing my minimum example.
I am running G
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
To Whom It May Concern:
This problem only appears in WindowsNT GNU make. If GNU make does
not support WindowsNT, please just indicate so.
I am using Wind River Systems (www.windriver.com) Tornado software which
employes GNU make as well as other GNU tools. I am using it in WindowsNT
platform.
26 matches
Mail list logo
