[bug #21661] Make expands command-line variable defnitions after/during every command invocation

URL: Summary: Make expands command-line variable defnitions after/during every command invocation Project: make Submitted by: bobbogo Submitted on: Wednesday 28/11/07 at 16:43 Severit

[bug #21661] Make expands command-line variable defnitions after/during every command invocation

Follow-up Comment #2, bug #21661 (project make): I set $var on the command-line. Note that it is not mentioned _anywhere_ inside the Makefile, and yet it (or its expression) seems to be being expanded whenever the Makefile runs a command --- _any_ and _all_ commands. Expected behaviour? (Regress

[bug #21661] Make expands command-line variable defnitions after/during every command invocation

Follow-up Comment #4, bug #21661 (project make): > If you put "var=value" in your makefile, then the left hand side of the variable will be re-expanded every time the variable "var" is referenced. Fine, but I have _not_ _referenced_ var _anywhere._ Why then is it being expanded? ___

[bug #21661] Make expands command-line variable defnitions after/during every command invocation

Follow-up Comment #6, bug #21661 (project make): Aha, that explains everything. You are right of course, it's not a regression (as I found out after digging out 3.79.1 and 3.80), so appologgies for any aspersions cast. Using something like "~" for the variable name on the cammand line is a decen

[bug #40371] Make 4.0 is not 8 bit clean

URL: Summary: Make 4.0 is not 8 bit clean Project: make Submitted by: bobbogo Submitted on: Fri 25 Oct 2013 10:55:27 AM GMT Severity: 3 - Normal Item Group: Bug

[bug #16928] Request for unique() function

Follow-up Comment #1, bug #16928 (project make): Have you seen the _uniq_ function from the make standard library? uniq = $(if $1,$(firstword $1) $(call uniq,$(filter-out $(firstword $1),$1))) ___ Reply to this item at:

[bug #42270] Make needs to canonicalise paths

URL: Summary: Make needs to canonicalise paths Project: make Submitted by: bobbogo Submitted on: Fri 02 May 2014 09:39:02 PM GMT Severity: 3 - Normal Item Group: Bug

make 3.79: core dump expanding target specific variables

pand.c:489: allocated_variable_append: Assertion `current_variable_set_list->next != 0' failed. Aborted (core dumped) $ All is OK with m:=hello on the command line (note the colon), and also running with make378. A similar situation exists with the current cygwin make (make-3.79.1-2 I believe) Regards,

Crash in Make 3.79.1 expanding target specific variables

ce shouldn't be there.] BUT the folowing crashes: $ make m=blah make: expand.c:489: allocated_variable_append: Assertion `current_variable_set_list->next != 0' failed. Aborted (core dumped) $ This crashes on all versions of 3.79.1 that I can find (SuSE, Red Hat, cygwin, m

[bug #17448] Function argument parsing inconsistent in treatment of whitespace

URL: Summary: Function argument parsing inconsistent in treatment of whitespace Project: make Submitted by: bobbogo Submitted on: Wednesday 08/16/2006 at 16:49 Severity: 3 - Normal

[bug #28456] Expansion of $$< is incorrect

Follow-up Comment #6, bug #28456 (project make): The handling of *$<* under *SECONDEXPANSION* seems well broken as of 4.2.1. With an implicit rule: $ cat Makefile .SECONDEXPANSION: %.2: %.1 $$(info [$$<] [$$@]) ; : $@ Success $ ls foo.1 Makefile $ make foo.2 [foo.2

[bug #65448] $(intcmp) problems with negative integers

: None ___ Follow-up Comments: --- Date: Mon 11 Mar 2024 02:23:24 PM UTC By: Robert Bogomip _intcmp_ complains when given non-integer input: $ make --eval '$(error [$(intcmp hello,7,small