[bug #66627] A target-specific variable side-effect on eval

Follow-up Comment #1, bug #66627 (group make): I forgot to register before posting this bug report. ___ Reply to this item at: ___ Message sent via Sava

[bug #66627] A target-specific variable side-effect on eval

URL: <https://savannah.gnu.org/bugs/?66627> Summary: A target-specific variable side-effect on eval Group: make Submitter: None Submitted: Thu 02 Jan 2025 08:00:10 PM UTC Severity: 3 - Normal

[bug #59230] Conditional assigment of a target specific variable prevents export

Update of bug #59230 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #59230] Conditional assigment of a target specific variable prevents export

URL: <https://savannah.gnu.org/bugs/?59230> Summary: Conditional assigment of a target specific variable prevents export Project: make Submitted by: dgoncharov Submitted on: Tue 06 Oct 2020 10:38:50 PM UTC Sever

[bug #59230] Conditional assigment of a target specific variable prevents export

Follow-up Comment #3, bug #59230 (project make): That is assignment of a global variable prevents export of a target specific variable. ___ Reply to this item at: <https://savannah.gnu.org/bugs/?59

[bug #59230] Conditional assigment of a target specific variable prevents export

Additional Item Attachment, bug #59230 (project make): File name: sv59230_assignment_of_a_global_variable_prevents_export_of_a_target_specific_variable.diff Size:1 KB

[bug #59230] Conditional assigment of a target specific variable prevents export

Follow-up Comment #4, bug #59230 (project make): The second patch fixes this second issue. ___ Reply to this item at: ___ Message sent via Savannah h

[bug #59230] Conditional assigment of a target specific variable prevents export

Follow-up Comment #1, bug #59230 (project make): The attached patch fixes the issue. ___ Reply to this item at: ___ Message sent via Savannah https:/

[bug #59230] Conditional assigment of a target specific variable prevents export

Follow-up Comment #2, bug #59230 (project make): However, the following example still fails, even with the attached patch applied. $ cat makefile all:; @echo hello=$$hello hello=sun dummy: hello?=world $ hello=moon make hello= ___ Repl

[bug #59230] Conditional assigment of a target specific variable prevents export

Additional Item Attachment, bug #59230 (project make): File name: sv59230_conditional_assignment_of_a_target_var Size:1 KB ___ Reply to

Re: append assignment operator in target specific variable

> 1. "foo" is simple variable. >so result have to be 100 but is 200 > > foo := > val := 100 > > all : foo += $(val) > all : > @echo foo : $(foo) > > val := 200 > > result is : 200 Yes, the result will become 200 because foo is not expanded until it is usead at the line "@echo foo : $

Re: append assignment operator in target specific variable

Sunday, May 19, 2019 08:52 To: bug-make@gnu.org Subject: append assignment operator in target specific variable * EXTERNAL EMAIL * GNU Make 4.2.1 Built for x86_64-pc-linux-gnu Copyright (C) 1988-2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <https://nam

append assignment operator in target specific variable

GNU Make 4.2.1 Built for x86_64-pc-linux-gnu Copyright (C) 1988-2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.

[bug #54727] foreach variable is not visible for a target specific variable definition in a recipe

Follow-up Comment #4, bug #54727 (project make): The first version of the patch is not good, make hangs on this test: $ echo '$(eval all: M:=$$(eval all: Q:=(eval all: T:=M)))' | ./make -f - The second version of the patch takes into account that the target-specific context may already b

Re: [bug #54727] foreach variable is not visible for a target specific variable definition in a recipe

ific,target_Y,M) > > > > all: target_X target_Y > > target_X target_Y:; $(info $@: M=$M) > > #### > > > > result: > > > > target_X: M=1 > > target_Y: M=g > > > > > > > > As we can see, the variable M has differe

[bug #54727] foreach variable is not visible for a target specific variable definition in a recipe

Additional Item Attachment, bug #54727 (project make): File name: make_bug_54727.patch Size:0 KB ___ Reply to this item at: ___ Message sent

Re: [bug #54727] foreach variable is not visible for a target specific variable definition in a recipe

: M=1 > target_Y: M=g > > > > As we can see, the variable M has different values for target_X and target_Y, > which is not expected. > > Outer foreach variables cannot be used inside the eval context, if the call > comes from a target-specif

[bug #54727] foreach variable is not visible for a target specific variable definition in a recipe

## result: target_X: M=1 target_Y: M=g As we can see, the variable M has different values for target_X and target_Y, which is not expected. Outer foreach variables cannot be used inside the eval context, if the call comes from a target-specific variable

Re: [bug #54727] foreach variable is not visible for a target specific variable definition in a recipe

foreach x,1,$(eval $@: F := $x)) ... if I may put words in their mouth, the OP is making the following claims: * Line 2 makes a target-specific variable A == 1 * Ditto on line 4 with B == 1 * Since 4 works && lines 2 / 5 are identical (except the latter is in the recipe body) they should have t

[bug #54727] foreach variable is not visible for a target specific variable definition in a recipe

this is works: $ echo 'all:; $(eval $$@: x:=1)$(info $x)' | make -f - result: 1 To ensure that the real target-specific variable is being used, please try the following makefile: ## x:=g all: a b a:; $(eval $$@: x:=t)$(info $@: $x) b:; $(info $@: $x) ## result: a: t b: g >

[bug #54727] foreach variable is not visible for a target specific variable definition in a recipe

whether you're defining a new target-specific variable for the current target inside it's recipe and generate an error or warning. I'll leave this open as an enhancement request to get better messaging around this situation. ___

[bug #54727] foreach variable is not visible for a target specific variable definition in a recipe

URL: <https://savannah.gnu.org/bugs/?54727> Summary: foreach variable is not visible for a target specific variable definition in a recipe Project: make Submitted by: mbuilov Submitted on: Tue 25 Sep 2018 02:48:25

Re: Fwd: Re: Target-specific variable in subdirectory problem

Hi Sven, Le jeudi 03 août 2017 à 16:46 +0100, Sven C. Dack a écrit : > it's a common practise to create a Makefile for each subdirectory and > have it include definitions from a parent Makefile. That's probably why > you don't see that many directory-spanning features in make. It's easier > to man

Fwd: Re: Target-specific variable in subdirectory problem

e the the top-level Makefile also defines FOO and includes Makefile.subs and hence prints out "Makefiles" for the last target "test-4". Cheers On 03/08/17 13:59, Benjamin Cama wrote: ... Concerning my real use case, it is just to define target-specific variables for

Re: Target-specific variable in subdirectory problem

Le jeudi 03 août 2017 à 15:06 +, Edward Welbourne a écrit : > Benjamin Cama (3 August 2017 17:00) > > Well, I tried: > > > >SUBDIR = $(dir $@) > >$(SUBDIR)/target-%: > > … > > > > But it doesn't work. But without a slash (which is already present at > > the end of $(SUB

Re: Target-specific variable in subdirectory problem

Le jeudi 03 août 2017 à 14:59 +0200, Benjamin Cama a écrit : > To further enhance my understanding of the “right” usage of Makefiles, > would you advise me to explicitly specify the subdirectory in the > target > definition? Because I feel that counting on pattern rules to match in > subdirectory i

Re: Target-specific variable in subdirectory problem

my recipe (with $*), and everything works as expected. It's just that > the global namespace is “polluted” by this variable which is used only > in my particular recipe. And this is where I may be mistaken on the > use > of target-specific variable: I

Re: Target-specific variable in subdirectory problem

s “polluted” by this variable which is used only in my particular recipe. And this is where I may be mistaken on the use of target-specific variable: I tend to use them as a kind of “private namespace” feature, when I define something that will be used only in one particular recipe. What we do in o

Re: Target-specific variable in subdirectory problem

could file an > enhancement request on Savannah if you like: > > https://savannah.gnu.org/bugs/?func=additem&group=make It indeed kind of look strange that the pattern-specific feature does not work in some particular case. I do not know what would be the “right” thing to do, tho

Re: Target-specific variable in subdirectory problem

> The example in his question makes very clear what he wants: he wants a > pattern-specific variable assignment. Most likely yes. If you look at the subject of this thread it says "Target-specific variable in subdirectory problem" so he probably only wants the variable to be set

Re: Target-specific variable in subdirectory problem

No. You're mistake is to assume to know what he wants from looking at his Makefile when you also know it's not working for him. You cannot know what it is he wants when he apparently fails to express it in a Makefile. So you're still only assuming. You base your assumption on the fact that he p

Re: Target-specific variable in subdirectory problem

On Wed, 2017-08-02 at 21:16 +0100, Sven C. Dack wrote: > I suggest you turn your attention towards him and ask him what he > wants. The example in his question makes very clear what he wants: he wants a pattern-specific variable assignment. The solution you provided was not a pattern-specific var

Re: Target-specific variable in subdirectory problem

Paul's interpretation appears to be the same as mine, and seems like the only straightforward interpretation of the OP's message. If that's the case (and Benjamin can tell us if it is not), I believe his message from 3:16 ET entirely explains the difference in behavior between test-% used in patter

Re: Target-specific variable in subdirectory problem

I suggest you turn your attention towards him and ask him what he wants. My example does exactly what I say it does. It's just not your place to tell me I'm wrong when you don't know what he wants his makefile to do and so far haven't responded to him and only to me. Or am I missing something

Re: Target-specific variable in subdirectory problem

On Wed, 2017-08-02 at 20:40 +0100, Sven C. Dack wrote: > It's my understanding that we don't actually know what Benjamin wants to > do, because nobody has asked. So I don't see how this would make me wrong. > >  From his mail am I assuming he wants his Makefile to print "BAR" for a > target "tes

Re: Target-specific variable in subdirectory problem

It's my understanding that we don't actually know what Benjamin wants to do, because nobody has asked. So I don't see how this would make me wrong. From his mail am I assuming he wants his Makefile to print "BAR" for a target "test-stem" as well as "subdir/test-stem", which is what he will get

Re: Target-specific variable in subdirectory problem

ly so this is identical to writing: FOO = BAR test-%: test-%: echo $(FOO) which clearly explains your output. > On 02/08/17 11:19, Benjamin Cama wrote: > > Hi, > > > > I may be doing something wrong, but the following Makefile gives me > > strange resu

Re: Target-specific variable in subdirectory problem

On Wed, Aug 2, 2017 at 3:03 PM, Sven C. Dack wrote: > Hello, > > try it with the following rules: > > test-%: $(eval FOO = BAR) > test-%: > echo $(FOO) FOO is a global variable in this case. Not sure what you're trying to demonstrate here. Kyle __

Re: Target-specific variable in subdirectory problem

kefile gives me strange results: the target-specific variable does not apply when used for a target in a subdirectory. test-%: FOO = BAR test-%: echo $(FOO) E.g.: $ make test-stem echo BAR BAR $ make subdir/test-ste

Re: Target-specific variable in subdirectory problem

Benjamin Cama (2 August 2017 12:19) > I may be doing something wrong, but the following Makefile gives me > strange results: the target-specific variable does not apply when used > for a target in a subdirectory. > >test-%: FOO = BAR >test-%: >

Target-specific variable in subdirectory problem

Hi, I may be doing something wrong, but the following Makefile gives me strange results: the target-specific variable does not apply when used for a target in a subdirectory. test-%: FOO = BAR test-%: echo $(FOO) E.g.: $ make test-stem

Re: Condtional target-specific variable assignment does not work as expected

I've grossly simplified the above example to show the gist of it, but the intermediate steps are all first-order targets for debugging and development purposes. I started using macros but the amount of nesting and $-escaping needed makes that approach fragile and hard for non-expert users to manage

Re: Condtional target-specific variable assignment does not work as expected

On Fri, Aug 9, 2013 at 12:59 PM, Ed Hutchins wrote: ... > In my case I'd like to have "init", "start" and "start_clean" end-user > targets which reuse common > targets which in turn depend on targets specified by the above semantic > intent. If there were a > true order-only operator (say ||), I c

Condtional target-specific variable assignment does not work as expected

The following Makefile: condset: COND ?= one condset: condset2 @echo $@ COND [$(COND)] condset2: COND ?= two condset2: condset3 @echo $@ COND [$(COND)] condset3: COND ?= three condset3: @echo $@ COND [$(COND)] outputs: condset3 COND [three] condset2 COND [two] condset COND [one] I would have

Determining Target Specific Variable Inheritance Path

Hi all, I am currently encountering unexpected target specific variable inheritance a very large and complex build. Claiming thousands of lines of makefile would not be an exaggeration. I need to understand how and why that particular variable definition is being inherited between two targets

[bug #34806] target-specific variable with conditional assignment generates garbage

Follow-up Comment #2, bug #34806 (project make): Would it be easy to isolate the related patch for you? If so, distros could integrate that before 3.83 comes out. So if it's easy, please attach the patch applied. Thanks! ___ Reply to thi

[bug #34806] target-specific variable with conditional assignment generates garbage

Update of bug #34806 (project make): Status:None => Duplicate Open/Closed:Open => Closed ___ Follow-up Comment #1: This has already been

[bug #34806] target-specific variable with conditional assignment generates garbage

URL: <http://savannah.gnu.org/bugs/?34806> Summary: target-specific variable with conditional assignment generates garbage Project: make Submitted by: None Submitted on: Sat 12 Nov 2011 12:06:18 AM UTC Sever

[bug #32872] Inheritance of target-specific variable not always suppressed by private

Update of bug #32872 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #32872] Inheritance of target-specific variable not always suppressed by private

Update of bug #32872 (project make): Triage Status:None => Verified ___ Follow-up Comment #1: I agree, this is a bug ___ Reply to this

[bug #32871] Incorrect content returned by $(value) in recipe for target specific variable

Update of bug #32871 (project make): Triage Status:None => Verified ___ Follow-up Comment #1: I agree, this is a bug. ___ Reply to this

[bug #32872] Inheritance of target-specific variable not always suppressed by private

URL: <http://savannah.gnu.org/bugs/?32872> Summary: Inheritance of target-specific variable not always suppressed by private Project: make Submitted by: None Submitted on: Mon 21 Mar 2011 20:07:50 UTC Severity: 3 -

[bug #32871] Incorrect content returned by $(value) in recipe for target specific variable

URL: <http://savannah.gnu.org/bugs/?32871> Summary: Incorrect content returned by $(value) in recipe for target specific variable Project: make Submitted by: None Submitted on: Mon 21 Mar 2011 19:11:39 UTC Sever

[bug #13554] Target-specific variable values inherited by sub-targets

Update of bug #13554 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Fixed Release:

[bug #25578] target without target specific variable setting receives setting from unrelated target

Follow-up Comment #2, bug #25578 (project make): Hm. The markup seems to have swallowed my "should be" section. Also, the email seems to have deleted ALL the backslashes. Anyway, you get the idea. ___ Reply to this item at:

[bug #25578] target without target specific variable setting receives setting from unrelated target

Update of bug #25578 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: The problem is you fo

[bug #25578] target without target specific variable setting receives setting from unrelated target

URL: <http://savannah.gnu.org/bugs/?25578> Summary: target without target specific variable setting receives setting from unrelated target Project: make Submitted by: None Submitted on: Fri 13 Feb 2009 02:15:37

Re: Please help with syntax for target specific variable

%% "Jai Maraj" <[EMAIL PROTECTED]> writes: jm> I'm having trouble using a 'target specific variable' . jm> I haven't used this feature before and am sure what I'm doing wrong. jm> Makefile content is jm> jaitest: MYVAR=friend j

Please help with syntax for target specific variable

Hi Support, Please help me out here. I'm having trouble using a 'target specific variable' . I haven't used this feature before and am sure what I'm doing wrong. Makefile content is jaitest: MYVAR=friend @echo Hello $(MYVAR) Command make -f jaimake.mk jaitest

Re: Bug with semicolon in target specific variable?

%% "Bhatt, Milan C" <[EMAIL PROTECTED]> writes: bmc> It seems GMAKE doesn't like having semicolons within the value of a bmc> target specific variable. It likes it just fine. bmc> a : SOME_VAR := c; d bmc> a : bmc>@echo $(SOME_VAR) If y

RE: Bug with semicolon in target specific variable?

n in GMAKE ;) Milan -Original Message- From: Johan Bezem [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 17, 2002 5:05 AM To: Bhatt Milan C Cc: '[EMAIL PROTECTED]' Subject: Re: Bug with semicolon in target specific variable? Semicolons have a special meaning in GNU-make. RTFM! Escapin

Re: Bug with semicolon in target specific variable?

Semicolons have a special meaning in GNU-make. RTFM! Escaping with \; might help. Didn't try, though. Johan Bezem CSK Software AG > "Bhatt, Milan C" wrote: > > Hello, > > It seems GMAKE doesn't like having semicolons within the value of a > target specif

Bug with semicolon in target specific variable?

Hello,   It seems GMAKE doesn't like having semicolons within the value of a target specific variable.     a : SOME_VAR := c; d a :    @echo $(SOME_VAR)   The above exampe gives me the following error:   c/bin/sh: d: Execute permission denied.gmake: *** [a] Error 127   So it prin

Re: target specific variable

Please try this patch. --- make-3.79.1/expand.cMon Jun 19 16:23:57 2000 +++ make/expand.c Wed Jan 17 13:28:41 2001 @@ -92,7 +92,7 @@  /* Recursively expand V. The returned string is malloc'd. */ -static char *allocated_variable_append PARAMS ((struct variable *v)); +static c

target specific variable

    Hi,       I have attached a tar'ed gzip'ed example.     After running `make', I asked myself: Where did the `-ggdb' flag go ???         I append flags to object files separately like this:     sources := main.c util.c     objects := $(sources:.c=.o)     $(objects): CFLAGS += -ggdb     mai

problem with target specific variable and double colon rule

Hi,   I'm using make 3.79.1 on Windows 2000:   output of: make -version   GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.Built for i386-pc-msdosdjgppCopyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000    Free Software Foundation, Inc.This is free software; see

Re: export, target-specific variable, and +=

%% Dan Grossman <[EMAIL PROTECTED]> writes: dg> Here is the smallest Makefile I've been able to get to crash gnumake: This bug has been reported and fixed in the GNU make sources. It'll be available in the next release of GNU make. Thanks for the report! --

export, target-specific variable, and +=

Here is the smallest Makefile I've been able to get to crash gnumake: = export X foo: X+=bar foo: touch foo = Note that there is no problem if += is changed to =. Note that there is no problem if the export directive is removed. Note that there is no problem if the vari

Re: GMAKE: Problem with target-specific variable values.

%% "Steven De Rango" <[EMAIL PROTECTED]> writes: sdr> I have found a problem where a variable set to a target-specific sdr> value does not maintain that value when used as a prerequisite sdr> for an explicit rule. The same problem has occurred using gmake sdr> versions 3.78.1 (Linux 2.2.

GMAKE: Problem with target-specific variable values.

Dear Sir/Madam,   I have found a problem where a variable set to a target-specific value does not maintain that value when used as a prerequisite for an explicit rule.  The same problem has occurred using gmake versions 3.78.1 (Linux 2.2.14-5.0 & Windows32 build) and 3.79.1 (Linux 2.2.19-7.

Re: target-specific variable problem

%% "Antonio Norkus" <[EMAIL PROTECTED]> writes: an> I'm using GNU make 3.74 on a HP 715/50 with HPUX 10.20 and have an> encountered a problem with target-specific variable. Target-specific variables are not supported in GNU make 3.74. Get a newer version.

target-specific variable problem

Hi, I'm using GNU make 3.74 on a HP 715/50 with HPUX 10.20 and have encountered a problem with target-specific variable. Using the following makefile; --- STRING="The default value of a variable" all: @echo $(STRING) v

[Fwd: Target specific variable problems]

9.1, running 'make' yields: > > foo > bar > foo snafu bar > > This seems to indicate a bug in target specific variable management, as > I would expect the third line to be 'bar snafu bar' because COMMAND is a > recursively expanded variable. Even more in

Re: [Fwd: Target specific variable problems]

I looked at it and my first reaction was that it's a bug. However, I haven't had enough time yet to dig into it; maybe I will over the Thanksgiving holiday. -- --- Paul D. Smith <[EMAIL PROTECTED]> Find some G

[Fwd: Target specific variable problems]

> b: BLAH := bar > > c: BLAH := bar > c: COMMAND += snafu $(BLAH) > > d: c > d: BLAH := baz > # end > > With make-3.79.1, running 'make' yields: > > foo > bar > foo snafu bar > > This seems to indicate a bug in target specific variable man

Target specific variable problems

bar This seems to indicate a bug in target specific variable management, as I would expect the third line to be 'bar snafu bar' because COMMAND is a recursively expanded variable. Even more interestingly, a 'make d' yields: baz snafu bar which also is not what I expect (which

Re: bug report (v3.77): target specific variable values

I believe this is an instance of a problem I've fixed for the next version of GNU make, which should be appearing fairly soon. If you like I can add you to the pretest list, if you want to try it and see if it solves your problem. -- -

bug report (v3.77): target specific variable values

Essentially, when using multiple target specific variable assignments with multiple targets, some of such variable assignments destroy other variable values. The variable values that are destroyed are those of other target specific assignments. The makefile demonstrating the problem runs as

Re: Target-specific variable corruption

This has already been fixed in the latest version of GNU make (currently 3.78.1). ftp://ftp.gnu.org/gnu/make/ Or mirrors. -- --- Paul D. Smith <[EMAIL PROTECTED]> Network Management Development "Please rema

Target-specific variable corruption

forward to helping in any way I can. thanks, -Brian # GNU Makefile illustrating target-specific variable corruption # Brian Poynor ([EMAIL PROTECTED]) define problem: This problem seems to be corruption when copying global variables into target-specific ones. In the example here, target