12

Makefile does not require to bound variable values by quotes.

For instance this will be accepted:

a := ls -l -a > out.txt

My problem is: If I want to do something like this:

a := ls -l -a > out
b := .txt
c := $(a)$(b)

If end of the line of variable $(a) has a white space, variable $(c) will look like this:

ls -l -a > out .txt

With white space after out!

This can cause errors.

Is there a way to globally ignore white spaces at end of line of all makefile variable values?

Gilles 'SO- stop being evil'
  • 829,060
user1985
  • 121
  • 5
    Rather than modifying all your variable declarations, how about removing whitespace from the end of lines? Any editor worth its salt can do this automatically for you. – l0b0 Mar 23 '16 at 17:24
  • 1
    I know how to remove all white spaces from end of all lines... I can also use "strip" to edit variables... The point is that the make file is given to users..... They sometimes forget and add white spaces at the end of the line.. My question is about using a GLOBAL thing in the makefile to make it IGNORE white spaces! – user1985 Mar 23 '16 at 18:00
  • 1
    IMO rather than protecting them from such trivial mistakes, you're better off letting them make the mistake and learn from it. Add a warning comment about EOL spaces at the top of the Makefile. Or are you also going to protect them from mistyping ls as sl or cat as cta and countless other trivial errors? – cas Mar 24 '16 at 02:49
  • e.g. you could alias cta=cat but that just encourages your users to become lazy and careless in what they type at the command line....because they become used to being protected from their own carelessness. protected until they run into a typo or other common mistake you haven't thought of. – cas Mar 24 '16 at 02:51
  • If you're giving this file to users to edit it might be beneficial to have a script that checks for whitespace at the end of lines and throws an error back to the user (where in the process this would happen is not something I can answer). That way they learn about it and you don't process it. Silently fixing it won't teach them and assuming they know what they are doing is obviously problematic. – jcollum Jul 15 '21 at 18:31
  • It is unjustified to consider all unwanted white space at the end of a variable definition a mistake. One may rightly want to make a comment after the definition, and as rightly put a space before the comment for readability. – Armali Nov 17 '21 at 06:40

3 Answers3

13

No, there's no way to change the way make parses variable definitions. If you can't change the point at which variables are defined, you'll have to change the point where they're used.

If you're using GNU make and the variables' values aren't supposed to have significant whitespace inside them, you can use the strip function.

c := $(strip $(a))$(strip $(b))
Gilles 'SO- stop being evil'
  • 829,060
  • This works, but reduces readability. Do you know why do it add the empty space in the first place, and if I can avoid it? Ah! I had to remove the spaces between the commas when calling the function :) – Lucas Bustamante Mar 14 '22 at 19:33
  • 1
    @LucasBustamante Make doesn't add spaces, but it doesn't remove them. If you write a=hello there are no spaces, but if you write a = hello there's a space on the left. And if you call functions, $(subst x,y,$(foo)) doesn't add spaces anywhere but $(subst x, y, $(foo)) adds a space wherever it replaces x by y, which is often undesirable. – Gilles 'SO- stop being evil' Mar 14 '22 at 19:40
-2

The space is not at the end of the lines -- the space is before .txt.

This works fine:

a:= ls -l -a >out
b:=.txt
c:=$(a)$(b)

all:
    @echo ${c}

There are also all types of text processing functions you can use too...but its generally "bad" to make things dependent on "certain amount (or none) of white space"

marty
  • 52
-2

You have space after out. I had the same issue, remove the space at the end of a variable.

Iskustvo
  • 957
Nonamer IV
  • 1
  • 1
    The OP explicitly says this in their question, and goes on to ask how to get make to remove it. – Chris Davies May 22 '18 at 06:16
  • @roaima There's a point to this though. What the questioner wants to do is the equivalent of fixing a syntax error in a script by pre-parsing the code with some tool before running it. It would be better to just fix the error. – Kusalananda May 22 '18 at 06:24
  • 1
    @Kusalananda the way this is written it's just repeating what the OP has already said. – Chris Davies May 22 '18 at 06:26