[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 #56446] Make shouldn't be running eval when expanding variables for export

Update of bug #56446 (project make): Item Group: Enhancement => Documentation Status:None => Fixed Assigned to:None => psmith Open/Closed:

[bug #54703] Incorrection expansion of := accumulator under $(eval …)

Follow-up Comment #5, bug #54703 (project make): @Paul, Sorry for the long long delay before I react to your reply « I didn't see a new attachment?», I justed missed the notification ! The proposal was in attachment (file #45105 make-patch.diff). After double checking it, I decided to make some

[bug #54703] Incorrection expansion of := accumulator under $(eval …)

Additional Item Attachment, bug #54703 (project make): File name: make-patch1.diff Size:4 KB ___ Reply to this item at:

Re: Expansion of $(eval..)

Paul Smith wrote: You probably want to escape the non-argument references, so that call will not run them and instead they will be passed to eval: define add_c_src VPATH += $(1) C_SRC += $$(addprefix $(1)/, $(2)) $$(info Number of 'C_SRC': $$(words $$(C_SRC)))

Re: Expansion of $(eval..)

On Sat, 2022-01-22 at 13:59 +0100, Gisle Vanem wrote: >define add_c_src> > VPATH += $(1) > C_SRC += $(addprefix $(1)/, $(2)) > $(info Number of 'C_SRC': $(words $(C_SRC))) >endef > >$(eval $(call add_c_src, frmts/ceos, ceosopen.c)) &

Expansion of $(eval..)

Hello list! I have this really large makefile and discovered the '$(eval..)' function was handy to use for this. Like: define add_c_src VPATH += $(1) C_SRC += $(addprefix $(1)/, $(2)) $(info Number of 'C_SRC': $(words $(C_SRC))) endef $(eval $(call a

Re: bug in documentation - eval function

On Wed, 2021-01-13 at 09:18 +0100, Piotr Jankowski wrote: > At least on GNU Make 3.81 the one with the equal sign does not work. > It does not cause a visible error but does not work. It works fine for all versions of GNU make 3.82 and above; 3.82 was released in July 2010. The online manual docu

bug in documentation - eval function

Hi, I possibly discovered a bug in the documentation on the manual page hosted at: https://www.gnu.org/software/make/manual/html_node/Eval-Function.html In the example makefile: define PROGRAM_template = $(1): $$($(1)_OBJS) $$($(1)_LIBS:%=-l%) ALL_OBJS += $$($(1)_OBJS) endef Should

[bug #56446] Make shouldn't be running eval when expanding variables for export

Follow-up Comment #2, bug #56446 (project make): I agree with Robert, this looks like a documentation issue. The behavior actually looks consistent to me. A simple way to avoid exporting certain variables/functions automatically (besides unexport) is to prefix them with an invalid character for a

[bug #56446] Make shouldn't be running eval when expanding variables for export

Follow-up Comment #1, bug #56446 (project make): Yes, _.EXPORT_ALL_VARIABLES_ should at least be *documented* for its danger regarding (forced) early expansion with the very first recipe being executed. This also breaks most usage of functions like _error_ in variables. As for this example, at le

[PATCH] Remove useless code in eval

* src/read.c (eval): Remove useless code. Without this patch, Oracle Studio 12.6 complains ‘"src/read.c", line 1405: warning: loop not entered at top’. --- src/read.c | 7 --- 1 file changed, 7 deletions(-) diff --git a/src/read.c b/src/read.c index 175d714..546280c 100644 --- a/

[bug #56446] Make shouldn't be running eval when expanding variables for export

URL: <https://savannah.gnu.org/bugs/?56446> Summary: Make shouldn't be running eval when expanding variables for export Project: make Submitted by: mark_galeck0 Submitted on: Thu 06 Jun 2019 01:47:17 AM UTC

[bug #55560] .SECONDEXPANSION and eval in target-specific prerequisite lists

eat this : as if it were a rule separator. Consider a rule like: some$$file:prereq ; echo hi Second, this line: all: $$(eval LIBRARY_OBJECTS \:= $$(OBJECTS)) $$(LIBRARY) does _NOT_ define a target-specific variable LIBRARY_OBJECTS (maybe you know that but it wasn't clear from y

[bug #55560] .SECONDEXPANSION and eval in target-specific prerequisite lists

Follow-up Comment #3, bug #55560 (project make): Please note: I made an error in the last post, the following line should be removed: $(WORKDIR)/%/$(LIBRARY) ; ___ Reply to this item at:

[bug #55560] .SECONDEXPANSION and eval in target-specific prerequisite lists

library.mk === WORKDIR := $(CURDIR)/.work LIBRARY := $(LIBDIR)/$(TARGET).so # This macro uses the stem of a pattern to export target-specific variables OBJECT_PATTERN = $(eval $*-OBJECTS := $(SOURCES:%.cc=%.o)) LIBRARY_TARGETS := all tests PHONY: $(LIBRARY_TARGETS) .SECONDEXPANSION: $(LIBRARY_TARGETS

[bug #55560] .SECONDEXPANSION and eval in target-specific prerequisite lists

Follow-up Comment #1, bug #55560 (project make): I think I have an understanding of what is happening here. Even though make is processing a separate Target, it's still already performed a first pass on all of the mentioned target'prerequisite lists s when entering the second expansion phase. This

[bug #55560] .SECONDEXPANSION and eval in target-specific prerequisite lists

URL: <https://savannah.gnu.org/bugs/?55560> Summary: .SECONDEXPANSION and eval in target-specific prerequisite lists Project: make Submitted by: None Submitted on: Thu 24 Jan 2019 04:33:32 PM UTC Severity: 3 -

[bug #54703] Incorrection expansion of := accumulator under $(eval …)

Additional Item Attachment, bug #54703 (project make): File name: make-patch.diffSize:3 KB ___ Reply to this item at: ___ Message sent

Re: [bug #54703] Incorrection expansion of := accumulator under $(eval …)

On Sep 25 2018, "Paul D. Smith" wrote: > It's a shame that autoconf doesn't give an error when it can't find a macro > but I guess it doesn't know the difference between a macro and some shell > commands. You can use m4_pattern_forbid to make that an error. Andreas. -- Andreas Schwab, SUSE La

[bug #54703] Incorrection expansion of := accumulator under $(eval …)

Follow-up Comment #4, bug #54703 (project make): I didn't see a new attachment? Regarding the builds, you'll need to install the Guile package before you can successfully run the autoconf stuff. You don't need to compile GNU make with guile but to rebuild the configure script we need the package

[bug #54703] Incorrection expansion of := accumulator under $(eval …)

Follow-up Comment #3, bug #54703 (project make): Dear both, Thank you so much for your help. I must admit that being familiar with MSDos, M4 and TeX, I should have paid more attention to this aspect. I was quite aware of doubling the $ when it concerned producing recipes with eval, for the

[bug #54703] Incorrection expansion of := accumulator under $(eval …)

Update of bug #54703 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #2: Thanks Michael. Vince

[bug #54703] Incorrection expansion of := accumulator under $(eval …)

Follow-up Comment #1, bug #54703 (project make): Hello. This is not a bug. Argument of eval is always expanded prior evalation. Let's see how this works. - ITERATIONS:=1 2 3 ACCUMULATOR:=Macron go home : WORD_1:=Macron WORD_2:=go WORD_3:=home define ACCUMULATE WORD:=$(WOR

[bug #54703] Incorrection expansion of := accumulator under $(eval …)

URL: <https://savannah.gnu.org/bugs/?54703> Summary: Incorrection expansion of := accumulator under $(eval …) Project: make Submitted by: vincentb1 Submitted on: Fri 21 Sep 2018 10:01:35 AM UTC Severity: 3 -

Re: Defining new targets with eval during secondary expansion?

> > ASDF = $(foreach x, ${1}, $(eval $(call ${0}_, ${1}, $(dirname ${1} > ${1} > define ASDF_ = > ${1} :| ${2} > ${2} : ; mkdir -p ${@} > endef > > $(call build/foo/bar/baz/mytarget) : other dependencies for mytarget > That last line should've read: $(ca

Re: Defining new targets with eval during secondary expansion?

> > This is a bit nicer but there's still some duplication. What I'd like to do > is replace the argument on the right hand side with $(dir $@). With > secondary > expansion enabled I could write something like this: > > mktargetdir = $(eval $(call m

Re: Defining new targets with eval during secondary expansion?

make seems to ignore the trailing slash in the prerequisite. As a workaround I can write '$$(@D)/.' (trailing dot) and it works fine. Anyway thanks, this is good enough for me. Thanks, Ismail Ismail Badawi wrote: > > >* I'm trying to define new targets with eval during seco

Re: Defining new targets with eval during secondary expansion?

Ismail Badawi wrote: > I'm trying to define new targets with eval during secondary expansion, but > apparently this is not allowed -- with make 4.2.1 I get an error like > this: > > Makefile:94: *** prerequisites cannot be defined in recipes. Stop. > > I found bugs

Defining new targets with eval during secondary expansion?

Hi folks, I'm trying to define new targets with eval during secondary expansion, but apparently this is not allowed -- with make 4.2.1 I get an error like this: Makefile:94: *** prerequisites cannot be defined in recipes. Stop. I found bugs #24588 and #24622 related to this. My use ca

Re: Documentation for eval() has a bug

Ah, nevermind, I just saw this. http://stackoverflow.com/questions/13260396/gnu-make-3-81-eval-function-not-working -- David. David Hart Limnu --- https://limnu.com On Sat, Nov 28, 2015 at 12:21 PM, David Hart wrote: > > Hi, I've run into this problem twice (because I forgot the

Documentation for eval() has a bug

Hi, I've run into this problem twice (because I forgot the first time) and spent some time debugging my code only to find I'd followed the gnu make manual's example, which appears to have a bug in it. Or, eval() or the define directive has a bug, I'm not sure which. (Appe

[bug #43363] Variable is broken after $(eval) within recipe

Follow-up Comment #1, bug #43363 (project make): It's fantastic that you've provided reproducible cases (although please attach the sample files directly to the bug in the future rather than using pastebin). However for errors this complex it would be really, really helpful if for each example yo

Re: Challenges around the combination of functions "call" and "eval"

On Wed, 2015-01-28 at 22:38 +0100, SF Markus Elfring wrote: > > $(eval ...) is a (relatively) recently implemented, very advanced > > feature that exists only in GNU make: no other implementation of make > > has anything like it (that I'm aware of). > > Since

Re: Challenges around the combination of functions "call" and "eval"

> $(eval ...) is a (relatively) recently implemented, very advanced > feature that exists only in GNU make: no other implementation of make > has anything like it (that I'm aware of). Since which program version are the functions "call" and "eval" generally avail

Re: Difficulties from the combination of functions "call" and "eval"

On Sun, 2015-01-18 at 22:28 +0100, SF Markus Elfring wrote: > > Without knowing exactly what you mean by "handling of rules with > > multiple output files" I can't say for sure, but I think it's unlikely > > that $(eval ...) can help with this. > > A

Re: Difficulties from the combination of functions "call" and "eval"

> Without knowing exactly what you mean by "handling of rules with > multiple output files" I can't say for sure, but I think it's unlikely > that $(eval ...) can help with this. A lot of rules can come into the situation to fiddle with multiple output files easily.

Re: Difficulties from the combination of functions "call" and "eval"

documentation: - make _expands_ variables and functions, as marked with a leading dollar-sign. This - make _executes_ recipes and the argument of the $(shell) function by passing the _expanded_ text to the shell - make _evaluates_ the its own input, the makefile, files that it includes, the

Re: Difficulties from the combination of functions "call" and "eval"

On Sun, 2015-01-18 at 20:50 +0100, SF Markus Elfring wrote: > > The rule of thumb is, if you're using $(eval ...) inside a recipe, > > you're doing something wrong. > > Which make function should be used for recipe generation instead then? If you just want to expand

Re: Difficulties from the combination of functions "call" and "eval"

>> The result should become components for recipes in my use case. > > As described before, this is not right. $(eval ...) is used to > internalize make syntax. The result of expanding $(eval ...) is the > _empty string_, so putting it in a recipe results in NOTHING being add

Re: Difficulties from the combination of functions "call" and "eval"

On Sun, 2015-01-18 at 20:38 +0100, SF Markus Elfring wrote: > > Try changing eval to info > > This introspection approach will not work in the moment > when I stumble on the mentioned error messages. Why will it not work? $(info ...) is a no-op statement. It can appear anywhe

Re: Difficulties from the combination of functions "call" and "eval"

> The rule of thumb is, if you're using $(eval ...) inside a recipe, > you're doing something wrong. Which make function should be used for recipe generation instead then? > $(eval ...) is for parsing MAKEFILE content. Do recipes belong also to each make script? > There

Re: Difficulties from the combination of functions "call" and "eval"

> Try changing eval to info This introspection approach will not work in the moment when I stumble on the mentioned error messages. > and then inspect the output to see if it makes sense as a makefile. The result should become components for recipes in my use case. > Write s

Re: Difficulties from the combination of functions "call" and "eval"

On Sun, 2015-01-18 at 13:07 -0600, Norbert Thiebaud wrote: > >> Then $(eval) is the Wrong Thing. > > > > I hope not … > > hope is not relevant... $(eval) _is_ the Wrong Thing(tm) for what you > seems to want to do The rule of thumb is, if you're using $(eval

Re: Difficulties from the combination of functions "call" and "eval"

With eval and call one can get confused quite easily. Try changing eval to info and then inspect the output to see if it makes sense as a makefile. Write small test makefiles that do small aspects of what you want and build them up step by step until you get the result you want when you introduce

Re: Difficulties from the combination of functions "call" and "eval"

On Sun, Jan 18, 2015 at 6:31 AM, SF Markus Elfring wrote: > > Yes. - The evaluated variable should produce shell commands for recipes. > I try to reuse it as a subfunction. then use $(call -- or possibly $$(call, if you want to defer the call to when the recipe get invoked) not $(eval

Re: Difficulties from the combination of functions "call" and "eval"

g attention! I hope that I am becoming better over time here. > Stop and *think*! I'll try that of course. > $(eval) takes as its argument a *CHUNK OF STANDALONE MAKEFILE*: > a variable assignment, and rule w/ or w/o recipe, an export, a define, > and if/endif block, etc. I un

Re: Difficulties from the combination of functions "call" and "eval"

On Sat, Jan 17, 2015 at 11:11 PM, SF Markus Elfring wrote: >> So that $(eval $(call GIBBERISH)) is wrong. Exactly *how* it's wrong >> depends on what the $(call) is supposed to return. Currently you're >> evaling something that doesn't look like a *STANDA

Re: Difficulties from the combination of functions "call" and "eval"

> So that $(eval $(call GIBBERISH)) is wrong. Exactly *how* it's wrong > depends on what the $(call) is supposed to return. Currently you're > evaling something that doesn't look like a *STANDALONE* chunk of > Makefile, which results in the error *in the eval*

[bug #43363] Variable is broken after $(eval) within recipe

URL: <http://savannah.gnu.org/bugs/?43363> Summary: Variable is broken after $(eval) within recipe Project: make Submitted by: rockdrilla Submitted on: Пнд 06 Окт 2014 06:49:39 Severity: 3 - Normal

[bug #39203] Command line option --eval applied multiple times

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

[bug #39203] Command line option --eval applied multiple times

Follow-up Comment #1, bug #39203 (project make): After I bit more thought I figured this might be related to the MAKEFLAGS changes, so I added $(info MAKEFLAGS=$(MAKEFLAGS)) to the makefile. It seems that MAKEFLAGS is accumulating --eval options, and on the fifth restart it has this value

[bug #39203] Command line option --eval applied multiple times

URL: <http://savannah.gnu.org/bugs/?39203> Summary: Command line option --eval applied multiple times Project: make Submitted by: None Submitted on: Fri 07 Jun 2013 17:03:11 UTC Severity: 3 - Normal

Re: Documentation for the eval function

> > If your version is 3.80 or newer, please cut/paste (exactly) your > makefile so we can see it. > I took the example from the documentation: http://www.gnu.org/software/make/manual/html_node/Eval-Function.html#Eval-Function $ make --version GNU Make 3.81 Copyright (C) 2006 F

Re: Documentation for the eval function

On Wed, 2013-05-22 at 20:13 +0200, Sascha Ziemann wrote: > Hi, > > I think the example in the documentation for the eval function is > broken. I copied the example to a file and tried it with "make clean". > The action for the clean target is "rm -f $(ALL_OBJS

Documentation for the eval function

Hi, I think the example in the documentation for the eval function is broken. I copied the example to a file and tried it with "make clean". The action for the clean target is "rm -f $(ALL_OBJS) $(PROGRAMS)". The PROGRAMS variable is set at the beginning to "server

Re: [bug #38433] Example for "eval" in documentation contains error with "define"

On Wed Feb 27 17:02:03 2013, guent...@gmail.com (Philip Guenther) wrote: > IMO, the suggestion that was proposed would reduce the overall > usability of the manual and increase the confusion. I seen it tried > in multiple ways** in other open source projects (and at my day job) > and the results

Re: [bug #38433] Example for "eval" in documentation contains error with "define"

On Wed Feb 27 14:07:42 2013, guent...@gmail.com (Philip Guenther) wrote: > Meanwhile, other people complain that the docs are too long; adding > "this feature was added in 3.8x" throughout the guide just makes it > longer and harder to read. It's not a costless addition. I completely disagree. L

Re: [bug #38433] Example for "eval" in documentation contains error with "define"

On Wed, 2013-02-27 at 19:04 -0800, David Boyce wrote: > I think you and the others in the "nay" camp may be being a bit > unfair. As far as I can see, nobody has proposed (in this thread) that > the entire manual be reworked to note the version in which each > feature appeared. You're absolutely

Re: [bug #38433] Example for "eval" in documentation contains error with "define"

On Wed, Feb 27, 2013 at 5:02 PM, Philip Guenther wrote: > Side note: I should make clear that I am not committer to GNU make and > do not speak for the project. I'm just a contributer to the lists, > answering questions where I can. > Likewise. > IMO, the suggestion that was proposed would re

Re: [bug #38433] Example for "eval" in documentation contains error with "define"

On Wed, Feb 27, 2013 at 2:42 PM, Sebastian Pipping wrote: > Paul and Philipp, Side note: I should make clear that I am not committer to GNU make and do not speak for the project. I'm just a contributer to the lists, answering questions where I can. > Daniel has a valid point here. You could b

[bug #38433] Example for "eval" in documentation contains error with "define"

Follow-up Comment #2, bug #38433 (project make): Paul and Philipp, Daniel has a valid point here. You could be a lot more welcoming on this case, why so hard on him? I hit the very same thing myself some time ago, just forgot to speak up myself. That documentation "bug" is the reason meta pro

Re: [bug #38433] Example for "eval" in documentation contains error with "define"

On Wed, 2013-02-27 at 13:56 -0800, Daniel Wagenaar wrote: > I appreciate your correction, but I still feel that the documentation > on the website would be more helpful if it at least mentioned that > older versions of make fail quietly when there is a "=" at the end of > the line. GNU make has be

Re: [bug #38433] Example for "eval" in documentation contains error with "define"

On 02/27/2013 02:07 PM, Philip Guenther wrote: On Wed, Feb 27, 2013 at 1:56 PM, Daniel Wagenaar wrote: I appreciate your correction, but I still feel that the documentation on the website would be more helpful if it at least mentioned that older versions of make fail quietly when there is a "="

Re: [bug #38433] Example for "eval" in documentation contains error with "define"

On Wed, Feb 27, 2013 at 1:56 PM, Daniel Wagenaar wrote: > I appreciate your correction, but I still feel that the documentation on the > website would be more helpful if it at least mentioned that older versions > of make fail quietly when there is a "=" at the end of the line. The reason > is tha

Re: [bug #38433] Example for "eval" in documentation contains error with "define"

On 02/27/2013 11:30 AM, Philip Guenther wrote: On Wed, Feb 27, 2013 at 11:25 AM, Daniel Wagenaar wrote: The example for the "eval" function in the documentation at http://www.gnu.org/software/make/manual/html_node/Eval-Function.html contains a syntax error that causes the examp

[bug #38433] Example for "eval" in documentation contains error with "define"

Update of bug #38433 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #1: That's a valid stateme

Re: [bug #38433] Example for "eval" in documentation contains error with "define"

On Wed, Feb 27, 2013 at 11:25 AM, Daniel Wagenaar wrote: > The example for the "eval" function in the documentation at > http://www.gnu.org/software/make/manual/html_node/Eval-Function.html contains > a syntax error that causes the example to fail quietly. The probl

[bug #38433] Example for "eval" in documentation contains error with "define"

URL: <http://savannah.gnu.org/bugs/?38433> Summary: Example for "eval" in documentation contains error with "define" Project: make Submitted by: wagenaar Submitted on: Wed 27 Feb 2013 07:25:20 PM GMT

Re: Possible bug with $(eval) and :=

's an example Makefile: > > > A = abcdefghijklmnop > B = $(eval B := $A)$B > > test: > @echo [$B] > @echo [$B] > > > On cygwin it seems to work fine: > [abcdefghijklmnopqr] > [abcdefghijklmnopqr] > > > But on Mac 10.6 as well as Ubuntu 12

Possible bug with $(eval) and :=

I've been using this thunk implementation as described http://www.cakoose.com/wiki/gnu_make_thunks, but recently came upon an anomaly on a different operating system. Here's an example Makefile: A = abcdefghijklmnop B = $(eval B := $A)$B test: @echo [$B] @echo [$B] On cygwi

Re: make: eval template example bug?

On Wed, 2012-11-07 at 12:33 +0100, Daniel Borkmann wrote: > Hi together, > > I have make 3.81 on a Debian stable machine. I tried out the example > from the eval function given in > http://www.gnu.org/software/make/manual/make.html#Eval-Function . The > example *only* works for

make: eval template example bug?

Hi together, I have make 3.81 on a Debian stable machine. I tried out the example from the eval function given in http://www.gnu.org/software/make/manual/make.html#Eval-Function . The example *only* works for me if I remove the trailing '=' character, as provided in the patch below. If

Re: [bug #36881] Sample code for $(eval) is incorrect and fails.

On Thu, 2012-07-19 at 13:32 -0400, David Boyce wrote: > I think it would be a good thing > if older manuals could be kept online, e.g. by adding a version level: > > http://www.gnu.org/software/make/manual/3.81/make.html > http://www.gnu.org/software/make/manual/3.82/make.html > > No, I'm not off

Re: [bug #36881] Sample code for $(eval) is incorrect and fails.

On Thu, Jul 19, 2012 at 1:19 PM, Philip Guenther wrote: > The info docs that are part of the installed binary package would > surely match the installed binary. > Either > info make > or > info 'gnu make' > > has worked on every system I've seen. All true, but this situation trips people

Re: [bug #36881] Sample code for $(eval) is incorrect and fails.

self up to date. ___Reply to this item at: ___ Message sent via/by Savannah http://savannah.gnu.org/ John Joganic July 18, 2012 5:38 PM URL: Summary: Sample code for $(eval) is incorrect and fails.

[bug #36881] Sample code for $(eval) is incorrect and fails.

Follow-up Comment #5, bug #36881 (project make): Sure but if you use the distro-provided program you should always use the distro-provided documentation as well, not documentation you find on the web. Distributions are by definition virtually always behind the upstream development. All distros s

Re: [bug #36881] Sample code for $(eval) is incorrect and fails.

On Thu, Jul 19, 2012 at 10:14 AM, John Joganic wrote: > I was more concerned over the inability to access the information online as > the vast majority of people who use make get it through binary package > managers. The NEWS file is not something that is conveniently available, and > all my syst

[bug #36881] Sample code for $(eval) is incorrect and fails.

Follow-up Comment #4, bug #36881 (project make): Fair enough. I stand corrected. I was more concerned over the inability to access the information online as the vast majority of people who use make get it through binary package managers. The NEWS file is not something that is conveniently availa

[bug #36881] Sample code for $(eval) is incorrect and fails.

Update of bug #36881 (project make): Status:None => Not A Bug Open/Closed:Open => Closed ___ Follow-up Comment #3: 3.82 is not a "point r

Re: [bug #36881] Sample code for $(eval) is incorrect and fails.

On 07/19/2012 08:03 AM, John Joganic wrote: > Follow-up Comment #2, bug #36881 (project make): > > Thank you for the information. > > I must say that I'm rather concerned that fundamental syntax has changed with > no mention in the manual. > AFAIU, the manual, being a reference manual, is just a

[bug #36881] Sample code for $(eval) is incorrect and fails.

Follow-up Comment #2, bug #36881 (project make): Thank you for the information. I must say that I'm rather concerned that fundamental syntax has changed with no mention in the manual. Many documentation efforts are comprehensive, indicating after what version specific features were added. Few p

[bug #36881] Sample code for $(eval) is incorrect and fails.

Follow-up Comment #1, bug #36881 (project make): This is actually one of the most common misunderstandings about GNU make. The online manual *always* describes the latest released version, which is currently 3.82. The syntax you use was introduced in 3.82, so was not available in 3.81, with the pr

[bug #36881] Sample code for $(eval) is incorrect and fails.

URL: <http://savannah.gnu.org/bugs/?36881> Summary: Sample code for $(eval) is incorrect and fails. Project: make Submitted by: jjoganic Submitted on: Thu 19 Jul 2012 12:38:40 AM GMT Severity: 3 -

Re: Unexpected failure in tricky use of eval

; sense as written. >>> >> In fact, it should have been s/$(LAZY)/$(LAZYVAR)/. Sorry for the confusion. > > It still doesn't make sense to me. There is no function "override"...? > > Did you mean $(eval override LAZYVAR := val) maybe? > *Face

Re: Unexpected failure in tricky use of eval

ave been s/$(LAZY)/$(LAZYVAR)/. Sorry for the confusion. It still doesn't make sense to me. There is no function "override"...? Did you mean $(eval override LAZYVAR := val) maybe? > > Can you describe in words what you're looking for? > > > Basically, a new kind of

Re: Unexpected failure in tricky use of eval

On 05/13/2012 09:45 PM, Paul Smith wrote: > On Sat, 2012-05-12 at 19:42 +0200, Stefano Lattarini wrote: >> BTW: to make it more easy to discover at make runtime whether the bug has >> been fixed in the make version in use, could a proper new entry be added >> to .FEATURES? Maybe 'can-have-lazy-var

Re: Unexpected failure in tricky use of eval

On Sat, 2012-05-12 at 19:42 +0200, Stefano Lattarini wrote: > BTW: to make it more easy to discover at make runtime whether the bug has > been fixed in the make version in use, could a proper new entry be added > to .FEATURES? Maybe 'can-have-lazy-variables'? (I know, I suck at choosing > names).

"Lazy" variables in GNU make (was: Re: Unexpected failure in tricky use of eval)

On 05/12/2012 07:42 PM, Stefano Lattarini wrote: > On 05/12/2012 05:21 PM, Stefano Lattarini wrote: >> On 05/12/2012 04:41 PM, Eldar Abusalimov wrote: >>> Stefano, >>> >>> This is a bug, and it has been described and fixed here: >>> https://savannah.gnu.org/patch/?7534 >>> >> Thank you very much fo

Re: Unexpected failure in tricky use of eval

On 05/12/2012 05:21 PM, Stefano Lattarini wrote: > On 05/12/2012 04:41 PM, Eldar Abusalimov wrote: >> Stefano, >> >> This is a bug, and it has been described and fixed here: >> https://savannah.gnu.org/patch/?7534 >> > Thank you very much for the reference. Too bad this bug will prevent > me from

Re: Unexpected failure in tricky use of eval

On 05/12/2012 04:41 PM, Eldar Abusalimov wrote: > Stefano, > > This is a bug, and it has been described and fixed here: > https://savannah.gnu.org/patch/?7534 > Thank you very much for the reference. Too bad this bug will prevent me from using the lazy-evaluation trick with any GNU make < 3.83 :

Re: Unexpected failure in tricky use of eval

\ > \ > xxxx \ > >var = $(eval var := $$(mufoofoo))$(var) >dummy: >: $(firstword $(var)) > &g

Unexpected failure in tricky use of eval

xx \ \ \ \ \ var = $(eval var := $

Re: Online manual: wrong define in eval section

On Sat, 2011-10-08 at 18:04 +0200, Georg Sauthoff wrote: > > It's not the manual that's outdated, it's your version of GNU make. > > oh, you are right. > > Somehow did not expect such a change in syntax at this age of GNU make or > between minor version numbers. There is always new syntax in eve

Re: Online manual: wrong define in eval section

On Sat, Oct 08, 2011 at 11:48:36AM -0400, Paul Smith wrote: Hi, > It's not the manual that's outdated, it's your version of GNU make. > The online manual always defines the latest version of GNU make, which > is currently GNU make 3.82. You're using GNU make 3.81, which is not > the latest, so

Re: Online manual: wrong define in eval section

On Sat, 2011-10-08 at 17:34 +0200, Georg Sauthoff wrote: > Hi, > > currently the online manual section on eval > > http://www.gnu.org/software/make/manual/make.html#Eval-Function > > contains an example with folowing line: > > define PROGRAM_template = > > In

Online manual: wrong define in eval section

Hi, currently the online manual section on eval http://www.gnu.org/software/make/manual/make.html#Eval-Function contains an example with folowing line: define PROGRAM_template = In comparison to that my local info page (make 3.81, Ubuntu 11.04) says: define PROGRAM_template And indeed the

[bug #32498] export within $(eval) within a $(call) broken?

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

[PATCH] expand debugging options to provide tracing of call to $(eval and $(call

At LibreOffice we are migrating our build system from a customized dmake to gmake. The design of the build system used involved a fairly intensive use of $(eval and $(call to implement an 'Object-Oriented' kind of system. This is nice when things works, but it is pretty hard to find

  1   2   3   >