Update: GNU Make 3.81, Ubuntu 12.04
I have a set of markdown files that I want to compile to (say) html files, so this is my rule:
%.html: %.md
pandoc $< -o $#
So make foo.html would convert foo.md into foo.html.
However, there are spaces in the source markdown filenames and I do not have the ability to control these, that is I can't change a setting to remove the spaces.
This means if I make foo\ bar.html, I get
make: *** No rule to make target `foo bar.html'. Stop.
How can I write a generic rule %.html: %.md where the prerequisite filename has spaces?
I can get around it by using:
foo\ bar.html: foo\ bar.md
pandoc $< -o $#
But then I must manually write out this rule for every such source file that I have, when I'd rather use the % construct. Is my only hope to do some sort of $(foreach f,$(get list of *.md files),$(eval $(call function_to_generate_rule)))?
It seems from what #binki says that GNU make 3.82 might not have this issue, but unfortunately I do not have the option to update from v3.81 that is on my Ubuntu 12.04 machine.
I managed to "solve" it like so by using SECONDEXPANSION to substitute spaces with backslash-space in the prerequisite (so a prerequisite of foo bar.md becomes foo\ bar.md).
# define a variable with a single space
space:=
space+=
.SECONDEXPANSION:
%.html: $$(subst $$(space),\$$(space),%).md
pandoc "$<" -o "$#"
Here is the log. Again, works on Ubuntu 12.04/GNU Make 3.81, perhaps if you have 3.82 you can use #binki's solution which seems more elegant.
Edit
Apparently make’s support for whitespace in inference rules depends on what variant of GNU Make you are using. It just magically works fine with Gentoo’s patched sys-devel/make-3.82-r4 (and fails with Gentoo’s make 3.81-r2). I did not notice any explanation in make-3.82’s ChangeLog or NEWS or the Gentoo patches when quickly checking them. So implicit rules working with whitespace could just be a fluke in make-3.82 itself or even from Gentoo’s patchset. Official GNU support for whitespace in targets is tracked in the still-open GNU Make bug #712.
Original misguided answer
You can use any quoting characters that your shell supports. make ignores them when performing macro substitution and passes them directly to the shell. For example,
.SUFFIXES: .md .html
.md.html:
pandoc "$(<)" > "$(#)"
results in $ make foo\ bar.html passing the shell pandoc "foo bar.md" > "foo bar.html". I decided to use the traditional style of specifying generic make rules instead of the GNU Make extension involving %, but you can do this with GNU Make’s %-style rules too, I assume.
This does not solve the potential problem of the filenames containing quote characters in them. I think that, simply, most people just avoid putting " or ' in filenames because of the likelihood of causing issues with Makefiles or other scripts. Or you could use a GNU Makefile extension to replace the " characdter with \", something that makes sh happy (we’re going to just ignore cmd for now because I don’t even…):
.SUFFIXES: .md .html
.md.html:
pandoc "$(subst ",\",$(<))" > "$(subst ",\",$(#))"
This was tested with a file called a"b"c.md which succeeded in creating a"b"c.html (disclaimer: I used discount’s markdown command instead of pandoc).
Related
we have few html file title with spaces in a folder which is a prerequisite for make rule. while executing, the rule has failed stating there is no rule to make the target.
do we have anything to handle spaces in make file prerequisite?
prerequisite = $(wildcard D:/HtmlHelp/*.html)
the above variable results below files list
D:/HtmlHelp/Order Coordination.html D:/HtmlHelp/OverThres.html D:/HtmlHelp/Pmu.html
First file name has a space , which executing the rule with this prerequisite list ,make returns below error.
gmake[2]: *** No rule to make target `D:/HtmlHelp/Order', needed by `rule1'. Stop.
If you replace:
prerequisite = $(wildcard D:/HtmlHelp/*.html)
with simply:
prerequisite = D:/HtmlHelp/*.html
then GNU make will work, although you will need to replace in your rules $# with "$#", etc. The wildcard expansion will then happen in the rules, as https://www.gnu.org/software/make/manual/html_node/Wildcard-Function.html states:
Wildcard expansion happens automatically in rules. But wildcard expansion does not normally take place when a variable is set...
You can see this by inserting the statement:
$(info $(prerequisite))
into your makefile.
Another approach, from Using makefile wildcard command for file names with spaces, would be to use something like:
prerequisite = $(shell find 'D:/HtmlHelp/' -name '*.html' | sed 's/ /\\ /g')
to escape the spaces.
Finally, Can GNU make handle filenames with spaces? has a number of suggestions, with several referencing the blog post https://www.cmcrossroads.com/article/gnu-make-meets-file-names-spaces-them.
I want to encode the the rule "to make <name>.done, you need all files of the pattern <name>.needed.*. I've attempted to write this with this Makefile:
%.done: $(wildcard %.needed.*)
cat $^ > $#
Yet when I run touch foo.needed.bar && make foo.done, all I get is
cat > foo.done
It appears the % inside $(wildcard) is being interpreted as a literal "%". How can I get it expanded to the right value ("foo" in this case)?
The % is just a placeholder for "any string" in pattern matching. It has no special meaning in the wildcard function and is interpreted literally.
You might attempt using $* instead (which would expand to the stem of the filename), but unfortunately it won't work either:
%.done: $(wildcard $*.needed.*)
The reason it doesn't work is that the automatic variables ($* is one of them) are not available for use in the dependency list.
The workaround is to request a secondary expansion for the target:
.SECONDEXPANSION:
%.done: $$(wildcard $$*.needed.*)
This will prompt GNU Make to go over the rule a second time after processing the Makefile as usual, expanding any escaped variables that weren't expanded the first time around. The second time around, the automatic variable have their appropriate values.
Here's what I am trying to do:
EXTRA_INCLUDE_PATHS = ../dir1/path with spaces/ \
../dir2/other path with spaces/
CPPFLAGS += $(addprefix -I,$(EXTRA_INCLUDE_PATHS))
I want to get “-I../dir1/path with spaces/ […]”, but I get instead: “-I../dir/path -Iwith -Ispaces/ […]”.
How do I espace spaces in addprefix? I've tried doing this trick, but it produces same result:
space =
space +=
#produces “-Isome -Ipath”
CPPFLAGS += $(addprefix -I,some$(space)path)
Don't do it! As #MadScientist points out, you need to eschew all space-containing filenames in a makefile unless you want to be very sad. A space is a list separator (including in lists of targets), and there is just no way around that. Use symbolic links in your file system to avoid them! (mklink on windows, or use cygwin make which understands cygwin symbolic links).
That said, in the current case (where you are not defining a list of targets, but merely a list of include dirs), you could use a single character to represent a space, only translating it right at the end.
EXTRA_INCLUDE_PATHS = ../dir1/path|with|spaces/ ../dir2/other|path|with|spaces/
CPPFLAGS += $(subst |, ,$(patsubst %,-I'%',${EXTRA_INCLUDE_PATHS}))
Check the result:
$(error [${CPPFLAGS}])
gives Makefile:3: *** [-I'../dir1/path with spaces/' -I'../dir2/other path with spaces/']. Stop.. Here, $CPPFLAGS is in sh format—the spaces are quoted with ' so that the compiler sees each -I as a single parameter. make simply does not have this level of quoting.
If all your include dirs start with the same character sequence, you can exploit this for use with the substitute command:
CPPFLAGS += $(subst ..,-I ..,$(EXTRA_INCLUDE_PATHS))
Check the result with:
$(info ${CPPFLAGS})
(this is a slightly different (maybe more elegant) version of #bobbogo's answer)
If you escape spaces with a backslash (\ ), you can replace the escaped space by a pipe symbol (|), add the prefix and then undo the replace operation:
EXTRA_INCLUDE_PATHS = ../dir1/path\ with\ spaces/ ../dir2/other\ path\ with spaces/
CPPFLAGS += $(subst |,\ ,$(addprefix -I,$(subst \ ,|,${EXTRA_INCLUDE_PATHS})))
I have a Makefile which has this line :
$(CROSS_COMPILE)$(CC) $(DLFLAGS) $(LIBPATH) -o $(OUTP)/$(SONAME) *.o $(LIBINCL)
This *.o expansion sometimes looks like 1.0 2.o 3.o 4.o. However, other times it can be 2.o 1.o 4.o 3.o (and other combinations). This causes the resulting shared object to have different checksums.
As a limited workaround, in some cases we change the line above to this :
$(CROSS_COMPILE)$(CC) $(DLFLAGS) $(LIBPATH) -o $(OUTP)/$(SONAME) $(sort $(wildcard *.o)) $(LIBINCL)
However, I can't do this fix for every source package. What I would like is for the shell (bash) to perform the glob substitution based on a sort of the filename, so that the '*.o' glob substitution above is consistent between machines and builds.
Any ideas ? Can I tell bash to (by default) change how it does globbing to accomplish what I want ?
I don't think it is a good idea to count on wildcard expansion to return filenames in a specific order -- but if you know that the filenames will be in a certain numeric interval, why not use brace expansion (https://www.gnu.org/software/bash/manual/bashref.html#Brace-Expansion)?
$ echo {1..4}.o
1.o 2.o 3.o 4.o
I have a directory containing several files, some of which have spaces in their names:
Test workspace/
Another directory/
file1.ext
file2.ext
demo 2012-03-23.odp
I use GNU's $(wildcard) command on this directory, and then iterate over the result using $(foreach), printing everything out. Here's the code:
FOO := $(wildcard *)
$(info FOO = $(FOO))
$(foreach PLACE,$(FOO),$(info PLACE = $(PLACE)))
Here's what I would expect to see printed out:
Test workspace
Another directory
file1.ext
file2.ext
demo 2012-03-23.odp
Here's what I would actually get:
Test
workspace
Another
directory
file1.ext
file2.ext
demo
2012-03-23.odp
The latter is obviously of no use to me. The documentation for $(wildcard) flat-out states that it returns a "space-separated list of names" but completely fails to acknowledge the huge problems this raises. Nor does the documentation for $(foreach).
Is it possible to work around this? If so, how? Renaming every file and directory to remove the spaces is not an option.
The bug #712 suggests that make does not handle names with spaces. Nowhere, never.
I found a blog post saying it's partially implemented by escaping the spaces with \ (\\ seems to be typo or formatting artefact), but:
It does not work in any functions except $(wildcard).
It does not work when expanding lists of names from variables, which includes the special variables $?, $^ and $+ as well as any user-defined variable. Which in turn means that while $(wildcard) will match correct files, you won't be able to interpret the result anyway.
So with explicit or very simple pattern rules you can get it to work, but beyond that you are out of luck. You'll have to look for some other build system that does support spaces. I am not sure whether jam/bjam does, scons, waf, ant, nant and msbuild all should work.
GNU Make does very poorly with space-separated filenames.
Spaces are used as delimiters in word list all over the place.
This blog post summarizes the situation well, but WARNING: it incorrectly uses \\ rather than \
target: some\ file some\ other\ file
some\ file some\ other\ file:
echo done
You can also use variables, so this would also work
VAR := some\ file some\ other\ file
target: $(VAR)
$(VAR):
echo done
Only the wildcard function recognizes the escaping, so you can't do anything fancy without lots of pain.
But don't forget that your shell uses spaces as delimiters too.
If I wanted to change the echo done to touch $#, I'd have to add slash to escape it for my shell.
VAR := some\ file
target: $(VAR)
$(VAR):
touch $(subst \,\\,$#)
or, more likely, use quotes
VAR := some\ file some\ other\ file
target: $(VAR)
$(VAR):
touch '$#'
In the end, if you want to avoid a lot of pain, both in GNU make, and in your shell, don't put spaces in your filenames. If you do, hopefully the limited capabilities of Make will be sufficient.
This method will also allow use of listed file names such as $? and user variables that are lists of files.
The best way to deal with spaces in Make is to substitute spaces for other characters.
s+ = $(subst \ ,+,$1)
+s = $(subst +,\ ,$1)
$(call s+,foo bar): $(call s+,bar baz) $(call s+,bar\ baz2)
# Will also shows list of dependencies with spaces.
#echo Making $(call +s,$#) from $(call +s,$?)
$(call s+,bar\ baz):
#echo Making $(call +s,$#)
$(call s+,bar\ baz2):
#echo Making $(call +s,$#)
Outputs
Making bar baz
Making bar baz2
Making foo bar from bar baz bar baz2
You can then safely manipulate lists of file names using all the GNU Make
functions. Just be sure to remove the +'s before using these names in a rule.
SRCS := a\ b.c c\ d.c e\ f.c
SRCS := $(call s+,$(SRCS))
# Can manipulate list with substituted spaces
OBJS := $(SRCS:.c=.o)
# Rule that has object files as dependencies.
exampleRule:$(call +s,$(OBJS))
# You can now use the list of OBJS (spaces are converted back).
#echo Object files: $(call +s,$(OBJS))
a\ b.o:
# a b.o rule commands go here...
#echo in rule: a b.o
c\ d.o:
e\ f.o:
Outputs
in rule: a b.o
Object files: a b.o c d.o e f.o
This info is all from the blog that everyone else was posting.
Most people seem to be recommending using no spaces in paths or using Windows 8.3 paths, but if you must use spaces, escaping spaces and substitution works.
If you are willing to rely on your shell a bit more, this gives a list which can hold names with spaces just fine:
$(shell find | sed 's: :\\ :g')
The original question said that "renaming is not an option", yet many commenters have pointed out that renaming is pretty much the only way Make can handle spaces. I suggest a middle way: Use Make to temporarily rename the files and then rename them back. This gives you all the power of Make with implicit rules and other goodness, but doesn't mess up your file naming scheme.
# Make cannot handle spaces in filenames, so temporarily rename them
nospaces:
rename -v 's/ /%20/g' *\ *
# After Make is done, rename files back to having spaces
yesspaces:
rename -v 's/%20/ /g' *%20*
You could call these targets by hand with make nospaces and make yesspaces, or you can have other targets depends on them. For example, you might want to have a "push" target which makes sure to put the spaces back in filenames before syncing files back with a server:
# Put spaces back in filenames before uploading
push: yesspaces
git push
[Sidenote: I tried the answer which suggested using +s and s+ but it made my Makefile harder to read and debug. I gave up on it when it gave me guff over implicit rules likes: %.wav : %.ogg ; oggdec "$<".]