I was using the $\ trick to concatenate lines in a makefile without adding spaces (so for example if I did:)
$(info TEST: 1$\
2)
I would get the expected output
TEST: 12
without a space between the 1 and the 2. I seem to have stumbled upon a corner case that's not acting as I expect however. If I have the following:
$(info TEST: [$(or \
,$\
)])
I get the following:
TEST: [$]
The previous example shows that the \ has precedence over the $, so it should resolve to $(or ,), which should be blank. Is this a bug in make, or is there an explanation to this behavior? (I'm using gnu make 4.2.1).
------ EDIT -------
I just verified this does not occur in make 3.81, and thus considering this a bug. I sent an email to the maintainers. Leaving this question open in case anyone else runs into the same issue
----- New Edit -----
Ok, update -- it seems that $(or) automatically strips all parameters. This is likely the crux of the problem -- $(or , $ ,) would strip each parameter before resolving $<space>... so it would have a second parameter of $ (no spaces), which resolves to ... $. Sooo... the question now becomes, is this considered correct behavior, or is this a bug?
Related
I have seen this question and has read its many answers. I understand that this problem usually (always??) appears because of a mistake in using tabs vs spaces in Makefiles. So far that is the general case.
In my case, I have found the error in the title but not when doing make with a Makefile I suspect.
I do:
make a_configuration_file
and I get
Makefile:1: *** missing separator. Stop.
I suppose this "1" means that the error is occurring in the first line of the file, right?
This a_configuration_file is actually a generated file and the first lines are copied here :
#
# Automatically generated file; DO NOT EDIT.
# Ambarella SDK Configuration
#
CONFIG_THREADX=y
CONFIG_BOOT_CORE_SRTOS=0
So my questions for my particular case are:
The "1" refers to the comment line "#"? or the CONFIG_THREADX line?
This configuration file is not using Tabs. So what could be the problem?
EDIT:
Robert tells me that the problem could be the end-of-line. I checked with cat -A a_configuration_file and it seems there are no \r characters (I ve had problems with this before so I learned how to check for end-of-line chars)
Wander Nauta tells me the problem is in the Makefile. Which Makefile should I check? Right now there is a Makefile in the directory from where I call make and it is like this
build/Makefile
no tabs or spaces
I also did cat -A Makefile and I got
build/Makefileroot#themachine.....
If you are wondering what is that, is just that it seems that the Makefile does not have an end of the line at the end, so the cat command prints the contents and the rest (root#themachine...) is just the normal line in the command line
EDIT2:
I think I am close to finding the error.
Originally the "Makefile" was a link as in
ls ./ -l
lrwxrwxrwx 1 1133 543 13 Mar 18 Makefile -> build/Makefile
However now it is just a plain text file
ls ./ -l
-rw------- 1 11250 10513 14 Jul 6 Makefile
Somehow in the linux-windows-linux transference the link condition got lost
In my case, I have found the error in the title but not when doing make with a Makefile I suspect.
The error in the title specifies the name of the file in which the error is encountered: Makefile. Thus, your suspicion about "not when doing so with a Makefile" is unfounded. Although it is possible to run make without a makefile, and doing so can even be advantageous, make will always read a makefile if it can find one by one of the default names it looks for.
Moreover, though it may not be obvious in this case, the name given in the message is not just a base name but a (relative) path to the file. It is therefore complaining about a file named Makefile in make's working directory.
Right now there is a Makefile in the directory from where I call make
and it is like this
build/Makefile
no tabs or spaces I also did cat -A Makefile and I got
build/Makefileroot#themachine.....
Those two claims do not appear to be consistent with each other. In any case, however, neither one attributes valid makefile content to the makefile in question. This is likely the cause of the error message, which would then be a bit misleading.
It looks like you may be trying to have one makefile specify that another make be run in the build/ directory -- a so-called "recursive make". There are a couple of variations on how that is done, and they differ slightly in effect, but here's a guess at what you might be after for that top-level Makefile:
all:
$(MAKE) -C build
Of course, that second line needs to be indented with a leading tab, not spaces.
That will cause the top-level make run to trigger a second make run with the build/ directory as the second's working directory.
I'm trying to print out the perforce file version of the make file when it's executed. I'm using the $Id$ tag, which expands to $Id: //repository/path/check.make#6 $ or the like and I want to print //repository/path/check.make#6 to a file (currently using echo). I can't figure out how to get make to take the # as part of the string and not the beginning of a comment. I tried:
str1 = $(subst \#,\\\#,'$Id: //repository/path/check.make#6 $')
and other variations but I keep getting:
unterminated call to function `subst': missing `)'. Stop.
It would help if you provided a full example of what you want. I don't really understand why you're trying to subst a hash with a backslash hash. If you showed us a full example, including how you get the string and also what you want to do with the variable ar1, we could actually give you advice.
But, the way to use hashes in GNU make is to put them into a variable:
HASH := \#
$(info HASH = $(HASH))
That's all I can say without more info.
ETA
Yes, I'm very familiar with keyword expansion... it originated with SCCS/RCS back in the day :).
I see, you mean, you want to put the $Id$ into your makefile, then when your makefile is checked out the value will be replaced. That wasn't clear to me.
I'm sorry to say that what you want to do is close to impossible. The problem is that you can't escape the value in the makefile because you're not writing the value into the makefile, Perforce is. And Perforce is not escaping it.
You have only two options that I can see:
First, don't try to put this into a make variable. There are many ways to do this, depending on what you really want. One way is to create a header file that contains const char* foo = "$Id$"; and let that be replaced. If you really want the ID of the makefile, but you only need it within a certain recipe, you can put it directly into that recipe:
myrecipe: ; echo '$$Id$$'
(I'm not actually sure the $$ trick here will work, it depends on how Perforce replaces things... if it doesn't you can use echo '$Id$x' you'll lose the dollar signs but keep the rest).
The only other option is to upgrade your version of GNU make to the latest (4.3). In that release, some broken handling of hash characters in the $(shell ...) function was fixed, which means you can use:
var1 := $(shell echo '$$Id$$')
and it will work (same caveats, and solutions, for $$ here as above).
Maybe I didn't get you correctly but the following works for an outside actor replacing $Id$ without escaping:
define PERFORCE_ID
$Id$
endef
PERFORCE_ID := $(word 2,$(value PERFORCE_ID))
$(info $(PERFORCE_ID))
As a test, I simply put in the text substitution from Perforce myself:
define PERFORCE_ID
$Id: //repository/path/check.make#6 $
endef
PERFORCE_ID := $(word 2,$(value PERFORCE_ID))
$(info Perforce id is: $(PERFORCE_ID))
Output:
Perforce id is: //repository/path/check.make#6
You can't have an unescaped literal # in a make assignment and not have it be interpreted as a comment character. But as a hack, you can have the shell extract this token from the current Makefile.
# $Id: //repository/path/check.make#6 $
str1 := $(shell sed '/[$$]Id[$$:]/!d;s/^\# [$$]Id: \(.*\) [$$].*/\1/' Makefile)
The sed script looks for the $Id$ or $Id: token in the Makefile itself by way of a regex which doesn't match itself; the doubled dollar sign is how you put a literal dollar sign in a Makefile. It extracts the contents of the field, and make assigns the output to str1. Because there is no literal # in the code which assigns the variable, no further escaping is necessary.
Demo: https://ideone.com/hWjnCp
This requires GNU Make, but that's apparently what you are using already. (Please tag such questions explicitly as gnu-make.)
For my make file I use a variable named VERSION_NUMBER which is passed from a build environment in the following form:
VERSION_NUMBER='#258'
Now, I wish to extract the number 258 from this string under make, but I'm unable to do so due to the special character '#'.
I've tried the following and it works (for now assume that the variable is locally defined in the makefile and not passed from the build environment):
VERSION_NUMBER:='\#258'
empty:=
quote:='
space:= $(empty) $(empty)
pound:=\#
extract:= $(subst $(quote),$(empty),$(VERSION_NUMBER))
$(info $$extract is [${extract}]) # Debug print
extract:= $(subst $(pound),$(empty),$(extract))
$(info $$extract is [${extract}]) # Debug print
This prints out the following:
$extract is [#258]
$extract is [258]
The problem however is that here I'm using the VERSION_NUMBER as '\#258' instead of '#258' and unfortunately I can't get it to work in any other way.
The backslash is here to escape the # symbol, so as it's not interpreted by make. I don't see where's your problem, because in your case it will not appear in your string.
Anyway you already hold the solution, which works for a var declared in your Makefile as well as for a var coming from the call to make. The only difference is that inside your Makefile you have to escape the # character.
Take this simple Makefile :
VERSION_NUMBER:='\#258'
pattern:=\#
# Remove the quotes and the hash symbol
PARSED_VERSION_NUMBER = $(subst ',,$(subst $(pattern),,$(VERSION_NUMBER)))
all:
#echo Version number is $(VERSION_NUMBER)
#echo Parsed version number is $(PARSED_VERSION_NUMBER)
If you call it with make all you will have this output :
Version number is '#258'
Parsed version number is 258
See how the backslash disappeared.
Now if you call it with make all VERSION_NUMBER='#286' you will have this output :
Version number is '#286'
Parsed version number is 286
As you can see it's exactly the same behavior.
I'm trying to make sense out of the multi-line define directive of GNU make and I cannot. Example:
define A
1
2
endef
all:
#echo W=$(word 1,$(A))
Running make produces a result I have expected the least:
W=1
make: 2: Command not found
make: *** [all] Error 127
It appears that part of $(A) has spilled outside the $(word) function.
Is it a bug or intended behavior? If the "spill" is intentional, how does it really works?
P.S. GNU make v3.81 on Linux/x64
The thing to remember here is that make stores each recipe as a single recursive variable. At the point that make decides that it must run your recipe, it expands that variable. Make then passes each line in the resulting expansion to a separate shell, stopping if any of those shell executions return an error.
In your example, before running anything make expands #echo W=$(word 1,$(A)).
$(A) becomes 1¶2 (dunno what this looks like on your browser, but I'm using ¶ to represent a newline character)
Now, 1¶2 is a single word as far as make is concerned, so $(word 1,1¶2) naturally expands to 1¶2 (can you see where this is going yet?)
This leaves make with the string #echo W=1¶2. Make dutifully passes the first line of this to the shell (without the # as that is special to make). The shell executes echo W=1.
make executes 2 in a new shell.
The second shell complains that it can't find the command 2.
So, yes, expected behaviour.
[Warning: slight simplification in the above where I gloss over the bit where make is able to elide the shell and invoke the command itself if the string has no shell metacharacters in it]
The $(word) function is splitting on spaces. Not whitespace, spaces.
There are no spaces in your A macro so nothing gets split.
Add a trailing space on the 1 line or a leading space on the 2 line and you get your expected behaviour.
This is consistent across GNU make 3.81, 3.82, 4.0, and 4.1 in some quick testing here.
The reason you see the "spill" as you called it is because of how the define is expanded. It is expanded literally, newline and all. (Think template expansion.)
So make expands the define into the call to $(word 1,...) then expands that result (the whole define including the newline) into the recipe template and ends up with two lines that it executes as the recipe.
Consider a macro like this:
define somecommands
echo foo
echo bar
echo baz
endef
all:
$(somecommands)
What would you expect to happen here? How many lines is the body of all? How many shells are run here? What commands are executed? The answer is three lines, three shells and three echo commands.
If the newlines weren't counted then you would effectively run echo foo echo bar echo baz in one command and get foo echo bar echo baz as output instead of the expected (and far more useful) foo, bar, and baz on three different lines.
I can't figure where my code is wrong. I'm trying to launch the "make" command on a C++-project in windows prompt (I installed mingw-get-inst-20120426 on my pc) and it gives me back always the same error:
Makefile:672: * missing separator. Stop.
This is the line 672 of my file:
&& $(MAKE) $(AM_MAKEFLAGS) DESTDIR="$$dc_destdir" uninstall \
I have check for hidden spaces in this line, but there are only tabs: I have no idea where the error is (I'm newbie to makefiles).
Can anybobody help me?
Thanks,
Stefano
You should show the rest of the rule, not just that one line. The problem is not on this line but on the lines before it. I'll make a guess and say that either (a) you've forgotten to add a backslash at the end of the previous line, or (b) you have a backslash but then you've also added some extra whitespace or whatever after the backslash; the backslash must be the last character on the line to be recognized as a continuation character.
It's possible that the variables $(MAKE) $(AM_MAKEFLAGS) include leading or trailing spaces, please post the context of this line in your Makefile, as-well as the values used for those variables.
Edit: I had intended my answer to be: the contents of $(MAKE) $(AM_MAKEFLAGS) likely include a trailing or leading space, thus causing this error.