I am looking for guidance here as I recently encountered an issue when it came to comparisons using ifeq on variables that originated from a top-level Makefile I have no control over, and it made me wonder if there is a way to sanitize or standardize variables so that I can consistently use the same type of comparison going forward.
This is the problem I ran into, notice the use of " around values.
my_target:
ifeq ($(strip $(TOP_VAR_1)), "VALUE")
#this comparison yields true
endif
ifeq ($(strip $(TOP_VAR_2)), VALUE)
#this comparison yields true
endif
I was able to get these comparisons to work by trial and error based on GNU's conditional syntax guide, but this took me a great amount of time to do so.
Previous attempts include playing around with strip and quotation marks on variables and values, yet those still yielded a false equality.
e.g.
my_target:
ifeq ($(strip $(TOP_VAR_1)), VALUE)
#this comparison yields false
endif
ifeq ($(strip $(TOP_VAR_2)), "VALUE")
#this comparison yields false
endif
It's very unclear what exactly your question is. And, since you didn't show us what the actual values of the TOP_VAR_1 or TOP_VAR_2 variables are, we can't really provide any guidance.
I will say two things: first if you use the ifeq (...) form, then GNU make completely ignores quotes (or rather, treats them as any other character and not special in any way). And second, the only thing the strip function does is remove extra whitespace. It doesn't do anything with quotes.
So in your examples:
ifeq ($(strip $(TOP_VAR_1)), "VALUE")
This will be true if the value of the TOP_VAR_1 variable is the string "VALUE" (including the quotes!!), possibly with leading or trailing whitespace (as in, it would match "VALUE" but it would NOT match " VALUE " or VALUE etc.)
ifeq ($(strip $(TOP_VAR_2)), VALUE)
This matches if TOP_VAR_2 is the string VALUE (without quotes!) possibly with leading or trailing whitespace (as in, it would match VALUE but it would NOT match "VALUE" etc.)
If you want to see what these variables contain the simplest way is using the info function:
$(info TOP_VAR_2='$(TOP_VAR_2)')
Whatever is inside the '' in the output is the string that ifeq will operate on. You can of course also add the strip function to see how that changes things.
Following my comment from above, a sanitizing function applied to variable contents would look like this:
sanitize-var = $(subst ',,$(subst `,,$(subst ",,$(strip $1))))
TOP_VAR_1_san := $(call sanitize-var,$(TOP_VAR_1))
TOP_VAR_2_san := $(call sanitize-var,$(TOP_VAR_2))
ifeq ($(TOP_VAR_1_san),FOO bar)
....
Related
I want to define a variable differently depending on another variables value in a makefile. I thought using conditionals would solve the problem, like this in the makefile:
ifeq ($(BOOT_FLAG),installed)
BOOT_TEST=$(BOOT_FLAG)
else
BOOT_TEST=no
endif
BOOT_DEFINE=$(BOOT_FLAG)
BOOT_FLAG=installed
.PHONY: all
all:
#echo $(BOOT_TEST)
#echo $(BOOT_DEFINE)
I expected the output to be:
installed
installed
but I got this instead:
no
installed
apparently the ifeq does not expand the BOOT_FLAG to installed
but setting of the BOOT_DEFINE variable manages to expand it correctly.
I read in the manual that:
"make evaluates conditionals when it reads a makefile. Consequently, you cannot use automatic variables in the tests of conditionals because they are not defined until commands are run"
but the BOOT_FLAG is not an automatic variable. Also if I move the definition of BOOT_FLAG to before the ifeq, then it works as I want it. However, I want to keep the current order of the definitions (and I don't understand why make does an exception to the order independence of the definitions when using conditions)
The answer is right there in the statement you quoted:
make evaluates conditionals when it reads a makefile.
Since make has evaluated the conditional when it read that line in the makefile, and the variable has not been defined when it read that line, there's no way that variables set after the conditional can take effect.
Just because the documentation lists one consequence of this behavior (the one that most people get confused by) doesn't mean that this is the only consequence of this behavior.
However, I want to keep the current order of the definitions
You can't.
(and I don't understand why make does an exception to the order independence of the definitions when using conditions)
It would be virtually impossible, and even if it could be done the resulting behavior would be almost indecipherable except in the most trivial situations. If you don't believe me, try to write down an algorithm describing how that could work. Remember to consider things like simple variable assignments, nested conditionals, variables used in target and prerequisite lists, variables that are intentionally reset in different parts of makefiles, etc.
ETA You could do it, by putting the ifeq into a define variable then using eval later, after BOOT_FLAG is set, to expand it. Seems gross to me but...
This is because makefile is evaulating the ifeq as it parses the file.
So when it gets to the ifeq..., then BOOT_FLAG is yet not set, so BOOT_TEST = no
Then you set BOOT_FLAG.
Then once all the variables are parsed, makefile will go through and run your rule - so in this case BOOT_DEFINE is evaluated to $(BOOT_FLAG) final value of installed
Try this:
$(info start - BOOT_FLAG=$(BOOT_FLAG))
ifeq ($(BOOT_FLAG),installed)
BOOT_TEST=$(BOOT_FLAG)
else
BOOT_TEST=no
endif
$(info after if - BOOT_FLAG=$(BOOT_FLAG))
BOOT_DEFINE=$(BOOT_FLAG)
BOOT_FLAG=installed
$(info after assignment - BOOT_FLAG=$(BOOT_FLAG))
.PHONY: all
all:
#echo $(BOOT_TEST)
#echo $(BOOT_DEFINE)
You will see various values printed at different times during the makefile parsing. On the first pass it evaluates the variables (and if's) and then on the second pass it can do the target rules.
As others noted the problem is that ifeq is expanded and evaluated in-place.
If you want to postpone the evaluation until some late moment, you must keep the whole expression inside of a recursive variable. Then the conditional could be implemented by $(if ...) function, instead of ifeq (okay, $(eval ifeq...) should also be doable, but... well, gross).
Of course, this is quite an overhead for such simple case, but nonetheless it could be done like this:
BOOT_TEST=$(if $(subst _installed,,_$(BOOT_FLAG)),no,installed)
BOOT_DEFINE=$(BOOT_FLAG)
BOOT_FLAG=installed
.PHONY: all
all:
#echo $(BOOT_TEST)
#echo $(BOOT_DEFINE)
I want to set a variable if it is empty. I tried in this way:
....
TEST := $(something)
...
TEST ?= $(something else)
The first $(something) may return an empty string, however the conditional assignment ?= works only if the previous variable is not set, not if empty.
Any elegant solution to set the variable if empty?
EDIT
I found this solution:
....
TEST := $(something)
...
TEST += $(something else)
TEST := $(word 1, $(TEST))
but I think that there will be one more elegant.
Any elegant solution to set the variable if empty?
GNU make is hardly known for elegant solutions. Unless you find trapdoors and minefields to be elegant. I know only of the two ways to accomplish what you want:
The standard ifeq/endif solution:
ifeq ($(TEST),)
TEST := $(something else)
endif
Use the $(if) function:
TEST := $(if $(TEST),$(TEST),$(something else))
One can try to package that construct into a function too, but that is inadvisable. The function would have the hidden pitfall of occasionally breaking the $(something else) if it contains the , (for which there are only wayward workarounds). (The built-in functions like $(if) are immune to the , bug.)
Elegance test is up to you.
Here's another alternative that I personally find quite elegant, because it's a one-liner and doesn't need the redundant else-branch:
TEST := $(or $(TEST),$(something else))
From GNU make, chapter 7.2, Syntax of Conditionals:
"Often you want to test if a variable has a non-empty value. When the value results from complex expansions of variables and functions, expansions you would consider empty may actually contain whitespace characters and thus are not seen as empty. However, you can use the strip function to avoid interpreting whitespace as a non-empty value. For example:
ifeq ($(strip $(foo)),)
text-if-empty
endif
will evaluate text-if-empty even if the expansion of $(foo) contains whitespace characters."
Folks, I think there's a simpler solution
KDIR ?= "foo"
From: What is ?= in Makefile
Just in case anyone stumbled upon putting the condition in the rule itself. below how I did it, thought it might help others.
In Makefile, suppose we have the following rule with check target and we need to check whether var was passed.
check:
#[ "${var}" ] && echo "all good" || ( echo "var is not set"; exit 1 )
To test this out, run the following commands
$ make check
var is not set
make: *** [check] Error 1
$ make check var=test
all good
So, Now we can pass the variable value or a default value in case it was not passed to a bash script that will be responsible to do the logic. something like the following:
#[ "${var}" ] && ./b.sh ${var} || ./b.sh 'ss'
Here's below what b.sh might look like, though you can add more logic to it.
#!/bin/sh
echo $1
In case you need to distinguish if a variable is undefined or just has an empty value, use $(origin VARNAME) function:
ifeq ($(origin VARNAME),undefined)
VARNAME := "now it's finally defined"
endif
Note that VARNAME is not surrounded by $() - you literally give the name of the variable.
Setting value to variable in Makefile if value defined
ifdef RELEASE_BRANCH
GIT_TAG=$(shell cat projects/${RELEASE_BRANCH}/GIT_TAG)
else
GIT_TAG=$(shell cat release/DEFAULT_GIT_TAG)
endif
I am trying to have a Makefile which is able to use different instances of g++ based on whether I give along a certain target or not. So: If I run make home I want CC to be the g++ executable in /usr/bin, and otherwise in some long path <longpath>/bin.
So I tried checking for my target:
ifeq ("$(TARGET)", "home")
GCCPATH = /usr
HSPARG = home
endif
$(info "$(TARGET)")
$(info "$#")
GCCPATH ?= <longpath>
CC = $(GCCPATH)/bin/g++
GCCLIBPATH = $(GCCPATH)/lib64
However, the outcome of this is:
$ make home
""
""
<further build information>
and GCCPATH is in all occasions equal to <longpath>.
Now my questions are:
1. What do I do wrong?
2. How to fix it?
First of all, make home doesn't set TARGET to home. So you have to execute make TARGET='home' to set it.
Secondly, make cares about spaces, including spaces after commas. So when you wrote ifeq ("$(TARGET)", "home"), make didn't toss away the space after the comma like you might have expected. So what make ended up comparing was "home" and " home".
You can see this by running make TARGET=' home' and seeing what you get. Remove that space and you'll fix the problem.
That said all your quoting isn't doing anything for make either. It doesn't generally care. Quotes are just literal characters to make in almost all places (except in ifeq "arg1" "arg2" cases, etc. and maybe one or two other places but I can't think of any offhand), so you don't need them in the calls to $(info) or even in your ifeq test since you are using the ifeq (arg1,arg2) version.
In GNU make, trailing comments appended to variable assignments prevent subsequent comparison (via ifeq) from working correctly.
Here's the Makefile...
A = a
B = b ## trailing comment
C = c
RESULT :=
ifeq "$(A)" "a"
RESULT += a
endif
ifeq "$(B)" "b"
RESULT += b
endif
ifeq "$(C)" "c"
RESULT += c
endif
rule:
#echo RESULT=\"$(RESULT)\"
#echo A=\"$(A)\"
#echo B=\"$(B)\"
#echo C=\"$(C)\"
Here's the output...
$ make
RESULT=" a c"
A="a"
B="b "
C="c"
As you can see from the displayed value of RESULT, the ifeq was affected by the presence of the comment in the assignment of B. Echoing the variable B, shows that the problem is not the comment, but the intervening space.
The obvious solution is to explicitly strip the whitespace prior to comparison like so...
ifeq "$(strip $(B))" "b"
RESULT += b
endif
However this seems error prone. Since the strip operation is not needed unless/until a comment is used, you can leave out the strip and everything will initially work just fine -- so chances are you won't always remember to add the strip. Later, if someone adds a comment when setting the variable, the Makefile no longer works as expected.
Note: There is a closely related issue, as demonstrated in this question, that trailing whitespace can break string compares even if there is no comment.
Question: Is there a more fool-proof way to deal with this issue?
This is not something particular to GNU Make; rather, make is defined by POSIX to work this way:
string1 = [string2]
The macro named string1 is defined as having the value of string2, where string2 is defined as all characters, if any, after the <equals-sign>, up to a comment character (#) or an unescaped <newline>. Any <blank> characters immediately before or after the <equals-sign> shall be ignored.
This can be construed as a feature allowing you to clearly create variables with trailing whitespace:
FOO = stuff # this macro has two trailing spaces
BAR = something else# and this one has none
though probably usually it would be clearer to reorganise the places you use $(FOO) rather than depend on it having obscure whitespace.
Probably the best way to deal with this is just to avoid it: have a convention that you do not put comments on variable definition lines (except very occasionally to make intentional whitespace explicit). Instead of writing this:
A = a # list of apples
B = b # list of bananas
C = c # list of carrots
write this:
# list of apples
A = a
# list of bananas
B = b
# list of carrots
C = c
This tends to be the style in GNU projects (see for example the bottom of this page), though I don't recall whether this is documented anywhere.
Incidentally, when examining whitespace you probably want to quote your variables in your echo command more:
rule:
#echo 'RESULT="$(RESULT)"'
In your echo RESULT=\"$(RESULT)\" version, $(RESULT) is not quoted from the shell, so tabs and multiple spaces are being misleadingly displayed as single spaces.
Here are some raw ideas that I have:
Make it a policy to always use strip with ifeq
Not using strip would be a rare exception and would require an explanation in the comments.
Don't manually set configuration variables inside of a Makefile
Find or create some other tool to do that.
maybe the POSIX shell will suffice (although I think the nuances of shell variables may be worse than those of make).
I suspect that the GNU build system (Autoconf/Automake/etc.) addresses this, but my feeling is that this is overkill for most purposes.
Use some kind of "lint" tool to find these kind of problems
I'm not aware of the existence of any such tool.
Modify GNU make to fix this problem.
Preferably minimizing the impact on existing Makefiles.
Modify the make language so that by default the trailing-spaces are stripped
Use a more modern build tool instead of GNU make
Ugly, but perhaps more foolproof. Anyone who edits this in the future might at least notice that you, perhaps, made it ugly on purpose.
A = $(strip a )##
B = $(strip b )## trailing comment
C = $(strip c )##
I'm trying to create a generic build template for my Makefiles, kind of like they discuss in the eval documentation.
I can't seem to get the wildcard function to work within an eval. The basic code I'm having issues with looks like this.
SRC_DIR = ./src/
PROG_NAME = test
define PROGRAM_template
$(1)_SRC_DIR = $(join $(SRC_DIR), $(1)/)
$(1)_SRC_FILES = $(wildcard $$($(1)_SRC_DIR)*.c)
endef
$(eval $(call PROGRAM_template, $(PROG_NAME)))
all:
#echo $(test_SRC_DIR)
#echo $(test_SRC_FILES)
#echo $(wildcard $(wildcard $(test_SRC_DIR)*.c)
When I run make with this, the output is
./src/test
[correct list of all .c files in ./src/test/]
Basically, the wildcard call within PROGRAM_template is not being eval'd as I expect it. The call results in an empty list.
The join call is being eval'd correctly though.
So, what am I doing wrong? My guess is that
$$($(1)_SRC_DIR)
is not correct, but I can't figure out the right way to do it.
EDIT
Once this was solved, it didn't take long for me to hit another issue with eval.
I posted it as a new question at
Workaround for GNU Make 3.80 eval bug
You need to double escape virtually all of the functions and variables when you use eval. In most cases, the only things that don't need to be double-escaped are function arguments (because the call function will fully expand them). In this case, you technically don't need to double-escape join or SRC_DIR either, but it will simplify your life if you just always double-escape all variables and functions when using eval.
The reason you need the double escapes is that expansion happens twice when using eval. The eval function itself performs expansion, and then expansion is done again when the block is finally parsed as makefile syntax (i.e. when it is actually evaluated).
The way you've got it written, wildcard is invoked on the string literal $( test_SRC_DIR)*.c. If you want, you can see this for yourself by replacing wildcard with info in your version and see what happens.
You need to hold off on actually invoking wildcard until the second expansion, so that it's argument is the result of the expansion of $(test_SRC_DIR).
Try this:
SRC_DIR = ./src/
PROG_NAME = test
define PROGRAM_template
$(1)_SRC_DIR = $$(join $$(SRC_DIR),$(1)/)
$(1)_SRC_FILES = $$(wildcard $$($(1)_SRC_DIR)*.c)
endef
$(eval $(call PROGRAM_template,$(PROG_NAME)))
all:
#echo $(test_SRC_DIR)
#echo $(test_SRC_FILES)
#echo $(wildcard $(test_SRC_DIR)*.c)
EDIT: After posting this, I thought I'd better test it out to make sure it actually works. In doing so, I discovered another problem. You should avoid putting spaces between the comma and argument when calling functions. It causes a literal space character to be prepended to the argument that is passed to the function and leads to unintended results. I've removed the spaces after the commas in the function calls in my version (while this isn't a problem for the call to join, I removed the space there as well just because it's a good habit to get into).