Here is the command I run
make -d -f dump.makefile
A the error I got:
Reading makefile `dump.makefile'...
dump.makefile:31: *** commands commence before first target. Stop.
Source
ifneq (,)
This makefile requires GNU Make.
endif
# force use of Bash
SHELL := /bin/bash
# function
today=$(shell date '+%Y-%m:%b-%d')
update-latest=$(shell ln -nf {$(call today),latest}.cfdict-"$(1)".localhot.sql)
# variables
credentials="$$HOME/.my.cfdict.cnf"
default: data-only structure-only csv-only all
data-only: what=data
argList=( --defaults-file="${credentials}" --no-create-db --no-create-info ) \
mysqldump "$${argList[#]}" cfdict > $(call today).cfdict-"${what}".localhot.sql
$(call update-latest,${what})
The line that trigger the error is $(call update-latest,${what}) with call the update-latest function.
Full gist available on github.
Question
I check for tabs/space, it seems correct.
Did I misuse the call or badly declare update-latest ?
The problem that causes the error you report is that you do not separate the target-specific variable definitions from the definitions of the rules. You currently have rules of this form:
data-only: what=data
... commands ...
You might be expecting that the data-only: what=data line defines the target-specific variable and the rule, but it does not.
What you need is to have one line for the variable declaration and then repeat the name of the target for the rule. Like this:
data-only: what=data
data-only:
... commands ...
So data-only, to take just one example, would become:
data-only: what=data
data-only:
argList=( --defaults-file="${credentials}" --no-create-db --no-create-info ) \
mysqldump "$${argList[#]}" cfdict > $(call today).cfdict-"${what}".localhot.sql
$(call update-latest,${what})
I see that you declare argList as a shell variable so it does not need to be changed.
You'll have to update similarly all targets that have target-specific variables in your Makefile.
Related
The example below is directly from the GNU make manual:
program: $(OBJECTS)
$(file >$#.in,$^)
$(CMD) $(CMDFLAGS) #$#.in
#rm $#.in
This works perfectly. However, if I reverse the order of $(file) and the external tool, the behavior is still the same: $(file) is executed first, and only then the external tool.
Is it possible to call an external tool in a recipe, and after the successful completion of the tool, use $(file) to process the log and create further files?
The external tool is a code generator that produces an unknown set of files. The recipe should parse the log file and create make include files. Works with echo/$(shell), but that's limited by the system command line length. Using a separate rule would certainly work, but can it be done in the same recipe?
GNU make will always expand all variables and functions in the entire recipe up front, before it starts to invoke any commands in the recipe. So you cannot have a $(file ...) function (for example) operate on the results of running some command in the same recipe.
So the short answer to your question is no, it can't be done in a single recipe the way you want.
It's possible, if you run the shell command using $(shell ) rather than directly putting it in a recipe. I've been using following wrapper for it, which checks the error code and discards the result:
# Same as `$(shell ...)`, but triggers a error on failure.
ifeq ($(filter --trace,$(MAKEFLAGS)),)
override safe_shell = $(shell $1)$(if $(filter-out 0,$(.SHELLSTATUS)),$(error Unable to execute `$1`, status $(.SHELLSTATUS)))
else
override safe_shell = $(info Shell command: $1)$(shell $1)$(if $(filter-out 0,$(.SHELLSTATUS)),$(error Unable to execute `$1`, status $(.SHELLSTATUS)))
endif
# Same as `safe_shell`, but discards the output and expands to a single space.
override safe_shell_exec = $(call space,$(call safe_shell,$1))
Then $(CMD) $(CMDFLAGS) #$#.in becomes $(call safe_shell_exec,$(CMD) $(CMDFLAGS) #$#.in).
Is there any way to create multiline functions out of Makefile commands?
I know we can do something like this to encapsulate a recipe (of shell commands) as a function:
define function
#echo 'First argument: $1'
#echo 'Second argument: $2'
endef
.PHONY test-function
test-function:
$(call function, a, b)
With this, running make test-function will give the output:
First argument: a
Second argument: b
I also know we can use the call directive with one-line macros consisting of make syntax/directives (example taken from here):
pathsearch = $(firstword $(wildcard $(addsuffix /$(1),$(subst :, ,$(PATH)))))
LS := $(call pathsearch,ls)
But let's say I wanted to call a macro made up of multiple make commands, including conditionals. How would I achieve that?
When I run make build-type=API build with the following Makefile:
define check-arguments
ifeq ($1, api)
#echo 'Building API'
else ifeq ($1, service)
#echo 'Building Service'
else
$$(error 'Build type must be API or Service')
endif
endef
.PHONY: build
build:
$(call check-arguments, $(build-type))
#echo 'Starting build'
...
...
I keep getting the error Makefile:13: *** missing separator. Stop..
You can use eval. The GNU Make Manual states:
...it [eval] allows you to define new makefile constructs that are not constant; which are the result of evaluating other variables and functions.
eval will parse ifeq and $(error) as part of the makefile instead of as commands for the recipe.
One thing to keep in mind is that eval parses its input by itself, without regard for the surrounding syntax of the makefile. This means that you cannot use it to define only part of a rule, like in your example:
build:
$(call check-arguments, $(build-type))
If we use $(eval $(call check-arguments, $(build-type))), then eval will parse the expansion of check-arguments by itself and complain because the recipe has no target. (See this answer.) The solution here is to include build: in check-arguments somehow.
While having $(eval) is fine, I would like to recommend a different approach, based on target resolution instead of conditionals, like so:
$ cat Makefile
supported_build_types := api service
.PHONY: build
build: build-$(build-type)
.PHONY: $(addprefix build-,$(supported_build_types))
$(addprefix build-,$(supported_build_types)): build-%:
#echo 'Building $*'
#echo 'Starting build'
.PHONY: build-
build-:
$(error Must provide build-type of: $(supported_build_types))
.PHONY: build-%
build-%:
$(error Unsupported build type: $*. Must be one of: $(supported_build_types))
This can allow easier extensibility and maintenance while keeping away nuisances of $(eval)s, $(call)s and appropriate escaping.
Running supported build types:
$ make build build-type=api
Building api
Starting build
$ make build build-type=service
Building service
Starting build
Invalid build type:
$ make build build-type=foo
Makefile:17: *** Unsupported build type: foo. Must be one of: api service. Stop.
Missing build type:
$ make build
Makefile:13: *** Must provide build-type of: api service. Stop.
I am trying to get the target_compile to work.
copy_shared_object:
cp shared_object.so ${CURRENT_DIR}
PROJECT_SIM_OPTS += -LDFLAGS -L${CURRENT_DIR},-lm -load
target_compile: copy_shared_object actual_compile_with_sim_opts
.
.
.
actual_compile_with_sim_opts:
.
.
.
I am getting the Error despite the fact that I have not added ;\ on the first line starting with cp
make: PROJECT_SIM_OPTS: Command not found
makefile:282: recipe for target 'copy_shared_object' failed
make: *** [copy_shared_object] Error 127
What you likely want is something like:
${CURRENT_DIR}/shared_object.so: shared_object.so
cp $^ $#
target_compile: PROJECT_SIM_OPTS += -LDFLAGS -L${CURRENT_DIR},-lm -load
target_compile: copy_shared_object actual_compile_with_sim_opts
#echo PROJECT_SIM_OPTS=${PROJECT_SIM_OPTS} ...
To explain a few things (and to reiterate #Beta's remarks): The variable ${CURRENT_DIR} is a makefile variable. It can come from either the environment or makefile. make will substitute the value for the variable name at its first phase (before it runs any rules). Therefore its value cannot be changed when running a rule. Makefile variables have a single $, and require braces around them if they're multi-character tokens.
${PROJECT_SIM_OPTS} is a target-specific makefile variable. It's still a makefile variable, so it cannot change its value when the make is executing the rules. That being said, its value is specific to the target_compile rule, and any rule that is being run as a result of that rule.
For shell variables, it's possible to set a value within a recipe, however, the scope of that value is that recipe line itself. In order to use shell variables you need to do $$shellvarname (with two $'s, as make expands $$ to $ before invoking the shell) That being said, each line of a recipe is run in a subshell, and any variable values will not be visible in other subshells. So, for example, if you have:
target: prereq
#shellVar="value"; echo "recipe1: shellVar is $$shellVar"
#echo "recipe2: shellVar is $$shellVar"
it will output:
recipe1: shellVar is value
recipe2: shellVar is
as recipe1's subshell does not communicate with recipe2's subshell, and therefore recipe2 is not aware of recipe1's value for the variable.
I have base Makefile for all my services, in some cases I want to use my default "test" target, in other cases I want to override\add to it. These are the files I have so far (and obviously its not working as expect..).
MakefileBase
test:
./.../run-tests.sh
Makefile
BASE_FILE := /path/to/MakefileBase
include ${BASE_FILE}
test:
#$(MAKE) -f $(BASE_FILE) test # un/comment this line in order to run the default tests.
# echo "custom test"
When I run the test with the first line commented out I get the following
Makefile:10: warning: overriding commands for target `test'
/.../MakefileBase:63: warning: ignoring old commands for target `test'
echo "no tests"
no tests
except of the warning it works as expected, the problem is when I try to use the parent function then I get the following errors:
Makefile:9: warning: overriding commands for target `test'
/.../MakefileBase:63: warning: ignoring old commands for target `test'
make[1]: test: No such file or directory
make[1]: *** No rule to make target `test'. Stop.
make: *** [test] Error 2
Actually, both answers so far are wrong or incomplete:
exit 0 in a rule will just exit the current shell (which runs only the exit 0 command, so it is a no-op in this case). So this won't override.
It's not true that you cannot override a command without warning. If it is not necessary that both targets have the same name, you can do:
MakefileBase
.PHONY: test-base
test-base:
echo base
%: %-base # handles cases where you don't want to override
Makefile1
include MakefileBase
.PHONY: test
test:
echo override
Makefile
include MakefileBase
.PHONY: test
test: test-base
echo append
As with double colon rules, the effects of each targets (on each other) have to be considered, especially if you move away from .PHONY (for example, files considered up-to-date because the other rule just updated them).
BTW, I don't see the problem with your approach (aside from the warning). For me it worked fine.
This is what double-colon rules are for:
test::
./.../run-tests.sh
and:
BASE_FILE := /path/to/MakefileBase
include ${BASE_FILE}
test::
#$(MAKE) -f $(BASE_FILE) test
This will "add to" an existing target. There is no way to override a target with a different recipe without incurring a warning.
If you want to do that the only way is to use variables to hold the recipe then override the variable value. For example:
test_recipe = ./.../run-tests.sh
test:
$(test_recipe)
and:
BASE_FILE := /path/to/MakefileBase
include ${BASE_FILE}
test_recipe = #$(MAKE) -f $(BASE_FILE) test
Hacky, but you can get add, and a limited form of override that can never be deeper than one override. Both use double colon rules.
add: use double colons on both rules
override: use double colons on both rules, appending command exit 0 to the last rule
# "addcmd" echoes "BA", "overridecmd" echoes "B"
addcmd ::
echo "A"
addcmd ::
echo "B"
overridecmd ::
echo "A"
overridecmd ::
echo "B"
exit 0
I want to comment one or more line(s) within a define directive in a Makefile so as the line is ignored when the directive is expanded. The goal is to place the commented line as a hint for the users of my Makefile to show an example of what could be into the define directive. The directive is expanded into a target.
In other words, I want that Makefile
define ECHO_FOO =
# #echo foo
endef
all:
#echo Before call
$(ECHO_FOO)
#echo After call
.PHONY: all
to have the same behavior than this one :
define ECHO_FOO =
endef
all:
#echo Before call
$(ECHO_FOO)
#echo After call
.PHONY: all
The issue is that the first Makefile gives me the following error :
process_begin: CreateProcess(NULL, ##echo foo, ...) failed.
make (e=2): The system cannot find the file specified.
Makefile:6: recipe for target 'all' failed
make: *** [all] Error 2
The GNU make:Makefile contents page states that :
Within a define directive, comments are not ignored during the definition of the variable, but rather kept intact in the value of the variable. When the variable is expanded they will either be treated as make comments or as recipe text, depending on the context in which the variable is evaluated.
But this doesn't explain in which specific case the # symbol is treated as a make comment or as a recipe text (which seems to be the problem I meet).
Can someone tell me how to have the # symbol treated as a comment mark in a define function ?
I have already tried all of the following lines with the idea of escaping the # symbol or changing the indentation but none of them gave me a correct output :
##echo foo
##echo foo
###echo foo
###echo foo
\##echo foo
\##echo foo
/##echo foo
/##echo foo
I'm running MinGW make 3.82 on Windows but I have already tried other implementations of make v3.82.90 and 4.1.
There's no way to do what you're asking for directly. The contents of the variable are expanded in a recipe context, so no matter what the variable expands to it will be considered part of the recipe and whatever characters are there will be passed to the shell.
Note you can use : in UNIX shells as well as Windows command.com, because : is the shell no-op operator. You have to add a space after it though otherwise it will try to run the command :echo which is not a valid command. However, further note that the shell will still expand the line! This means that if you use backquotes etc. then those still are expanded. Also note that since it's a statement, semicolon will stop it. So for example:
define ECHO_FOO
: echo hi `echo there 1>&2` ; echo bye
endef
all: ; #$(ECHO_FOO)
Here, the hi won't be printed because the echo command is not run, but the backticks are still expanded so there will be printed (to stderr) and the semicolon ends the "no-op" command so bye will also be printed.
If your commands are simple enough then : will work, but if they're that simple one wonders why you're using define...
Another option is just to override the variable, rather than comment it out:
define ECHO_FOO =
#echo foo
endef
ECHO_FOO =
ETA:
In the comments you affirm that the command is simple. I don't quite know what you mean by could be expanded by the final user or why that makes a difference.
But what I was alluding to is that if you have a simple command you can just write:
ECHO_FOO = echo hi
and not use define. define is only needed for complicated commands: really it's only required for commands that contain un-escaped newlines.
And, if you write:
ECHO_FOO =# echo hi
then you ARE commenting out the content of the variable using make comments, not shell comments, so it will work everywhere.
On Windows, you can use : as a comment character. The traditional comment keyword in MS-DOS is REM (as in "remark").