Passing arguments to "make run"

Question

I use Makefiles.

I have a target called run which runs the build target. Simplified, it looks like the following:

prog: ....
  ...

run: prog
  ./prog

Is there any way to pass arguments? So that

make run asdf --> ./prog asdf
make run the dog kicked the cat --> ./prog the dog kicked the cat

Answer 1

I don't know a way to do what you want exactly, but a workaround might be:

run: ./prog
    ./prog $(ARGS)

Then:

make ARGS="asdf" run
# or
make run ARGS="asdf"

Answer 2

This question is almost three years old, but anyway...

If you're using GNU make, this is easy to do. The only problem is that make will interpret non-option arguments in the command line as targets. The solution is to turn them into do-nothing targets, so make won't complain:

# If the first argument is "run"...
ifeq (run,$(firstword $(MAKECMDGOALS)))
  # use the rest as arguments for "run"
  RUN_ARGS := $(wordlist 2,$(words $(MAKECMDGOALS)),$(MAKECMDGOALS))
  # ...and turn them into do-nothing targets
  $(eval $(RUN_ARGS):;@:)
endif

prog: # ...
    # ...

.PHONY: run
run : prog
    @echo prog $(RUN_ARGS)

Running this gives:

$ make run foo bar baz
prog foo bar baz

Answer 3

for standard make you can pass arguments by defining macros like this

make run arg1=asdf

then use them like this

run: ./prog $(arg1)
   etc

References for make Microsoft's NMake

Answer 4

TL;DR don't try to do this

$ make run arg

instead create script build_and_run_prog.sh:

#! /bin/sh
# rebuild prog if necessary
make prog
# run prog with some arguments
./prog "$@"

and do this:

$ ./build_and_run_prog.sh arg

Read on for some explanation of why this is the most reasonable choice and why the other alternatives are best avoided

---

Answer to the stated question: how to pass arguments to a make target

you can use a variable in the recipe

run: prog
    ./prog $(var)

then pass a variable assignment as an argument to make

$ make run var=arg

this will execute ./prog arg.

But beware of pitfalls.

Most notably to awkwardness when passing arguments with spaces. You will have to do it like this:

$ make run var="foo bar\ baz"

this will execute ./prog foo "bar baz".

I will elaborate about the pitfalls of this method and others further below.

---

Answer to the assumed intention behind your question: You want to run prog with some arguments but have it rebuild before running if necessary.

Create a script which rebuilds if necessary then runs prog with args

build_and_run_prog.sh:

#! /bin/sh
# rebuild prog if necessary
make prog
# run prog with some arguments
./prog "$@"

This script makes the intention very clear. It uses make to do what it is good for: building. It uses a shell script to do what it is good for: batch processing.

Plus you can do whatever else you might need with the full flexibility and expressiveness of a shell script without all the caveats of a makefile.

Also the calling syntax is now practically identical:

$ ./build_and_run_prog.sh foo "bar baz"

compared to:

$ ./prog foo "bar baz"

contrast to

$ make run var="foo bar\ baz"

---

Background explanation of how make handles arguments:

Make is not designed to pass arguments to a target. All arguments on the command line are interpreted either as a goal (a.k.a. target), as an option, or as a variable assignment.

so if you run this:

$ make run foo --wat var=arg

make will interpret run and foo as goals (targets) to update according to their recipes. --wat as an option for make. And var=arg as a variable assignment for make.

the only chance you have to pass information from the command line to use inside a recipe is via variable assignment.

for more details see the gnu manual on how to run make

---

Why I recommend against variable assignment

$ make run var=arg

and the variable in the recipe

run: prog
    ./prog $(var)

This is the most "correct" and straightforward way to pass arguments to a recipe. but while it can be used to run a program with arguments it is certainly not designed to be used that way. See the gnu manual on overriding

In my opinion this has one big disadvantage: what you want to do is run prog with argument arg. but instead of writing:

$ ./prog arg

you are writing:

$ make run var=arg

this gets even more awkward when trying to pass multiple arguments or arguments containing spaces:

$ make run var="foo bar\ baz"
./prog foo bar\ baz
argcount: 2
arg: foo
arg: bar baz

compare to:

$ ./prog foo "bar baz"
argcount: 2
arg: foo
arg: bar baz

for the record this is what my prog looks like:

#! /bin/sh
echo "argcount: $#"
for arg in "$@"; do
  echo "arg: $arg"
done

also note that you should not put $(var) in quotes in the makefile:

run: prog
    ./prog "$(var)"

because then prog will always get just one argument:

$ make run var="foo bar\ baz"
./prog "foo bar\ baz"
argcount: 1
arg: foo bar\ baz

All this is why I recommend against this route.

---

For completeness here are some other methods to "pass arguments to make run".

Method 1:

run: prog
    ./prog $(filter-out $@, $(MAKECMDGOALS))

%:
    @true

filter out current goal from list of goals. create catch all target (%) which does nothing to silently ignore the other goals.

Method 2:

ifeq (run, $(firstword $(MAKECMDGOALS)))
  runargs := $(wordlist 2, $(words $(MAKECMDGOALS)), $(MAKECMDGOALS))
  $(eval $(runargs):;@true)
endif

run:
    ./prog $(runargs)

if the target is run then remove the first goal and create do nothing targets for the remaining goals using eval.

both will allow you to write something like this

$ make run arg1 arg2

problems of method 1:

• Arguments that start with a dash will be interpreted by make and not passed as a goal.

    $ make run --foo --bar
  

  workaround

    $ make run -- --foo --bar
  

• Arguments with an equal sign will be interpreted by make and not passed

    $ make run foo=bar
  

  no workaround

• Arguments with spaces is awkward

    $ make run foo "bar\ baz"
  

  no workaround

• If an argument happens to be run (equal to the target) it will also be removed

    $ make run foo bar run
  

  will run ./prog foo bar instead of ./prog foo bar run

  workaround possible with method 2

• If an argument is a legitimate target it will also be run.

    $ make run foo bar clean
  

  will run ./prog foo bar clean but also the recipe for the target clean (assuming it exists).

  workaround possible with method 2

• When you mistype a legitimate target it will be silently ignored because of the catch all target.

    $ make celan
  

  will just silently ignore celan.

  workaround is to make everything verbose. so you see what happens. but that creates a lot of noise for the legitimate output.

problems of method 2:

• If an argument has same name as an existing target then make will print a warning that it is being overwritten.

  no workaround that I know of

• Arguments with an equal sign will still be interpreted by make and not passed

  no workaround

• Arguments with spaces is still awkward

  no workaround

• Arguments with space breaks eval trying to create do nothing targets.

  workaround: create the global catch all target doing nothing as above. with the problem as above that it will again silently ignore mistyped legitimate targets.

• it uses eval to modify the makefile at runtime. how much worse can you go in terms of readability and debugability and the Principle of least astonishment.

  workaround: don't!

I have only tested using gnu make. other makes may have different behaviour.

---

gnu make manual

https://www.gnu.org/software/make/manual/html_node/index.html

Answer 5

You can pass the variable to the Makefile like below:

run:
    @echo ./prog $$FOO

Usage:

$ make run FOO="the dog kicked the cat"
./prog the dog kicked the cat

or:

$ FOO="the dog kicked the cat" make run
./prog the dog kicked the cat

---

Alternatively use the solution provided by Beta:

run:
    @echo ./prog $(filter-out $@,$(MAKECMDGOALS))
%:
    @:

%: - rule which match any task name; @: - empty recipe = do nothing

Usage:

$ make run the dog kicked the cat
./prog the dog kicked the cat

Answer 6

Here's another solution that could help with some of these use cases:

test-%:
    $(PYTHON) run-tests.py $@

In other words, pick some prefix (test- in this case), and then pass the target name directly to the program/runner. I guess this is mostly useful if there is some runner script involved that can unwrap the target name into something useful for the underlying program.

Answer 7

No. Looking at the syntax from the man page for GNU make

make [ -f makefile ] [ options ] ... [ targets ] ...

you can specify multiple targets, hence 'no' (at least no in the exact way you specified).

Answer 8

You can explicitly extract each n-th argument in the command line. To do this, you can use variable MAKECMDGOALS, it holds the list of command line arguments given to 'make', which it interprets as a list of targets. If you want to extract n-th argument, you can use that variable combined with the "word" function, for instance, if you want the second argument, you can store it in a variable as follows:

second_argument := $(word 2, $(MAKECMDGOALS) )

Answer 9

run: ./prog looks a bit strange, as right part should be a prerequisite, so run: prog looks better.

I would suggest simply:

.PHONY: run

run:
    prog $(arg1)

and I would like to add, that arguments can be passed:

1. as argument: make arg1="asdf" run
2. or be defined as environment: arg1="asdf" make run

Answer 10

Not too proud of this, but I didn't want to pass in environment variables so I inverted the way to run a canned command:

run:
    @echo command-you-want

this will print the command you want to run, so just evaluate it in a subshell:

$(make run) args to my command

Answer 11

Here is my example. Note that I am writing under Windows 7, using mingw32-make.exe that comes with Dev-Cpp. (I have c:\Windows\System32\make.bat, so the command is still called "make".)

clean:
    $(RM) $(OBJ) $(BIN) 
    @echo off
    if "${backup}" NEQ "" ( mkdir ${backup} 2> nul && copy * ${backup} )

Usage for regular cleaning:

make clean

Usage for cleaning and creating a backup in mydir/:

make clean backup=mydir

Answer 12

Building a bit on idelic answer.
You can create a generic "function" to fetch parameters using the following:

define fetch_parameter
    $(eval target_name:= $(firstword $(MAKECMDGOALS)))
    $(eval varname := $(target_name)_value)
    $(eval $(varname) := $(wordlist 2,$(words $(MAKECMDGOALS)),$(MAKECMDGOALS)))
    $(eval $($(varname))::;@:)
endef

You can then user it in your target like so:

my-target: res := $(call fetch_parameter)
my-target: ## Example target. Usage: make my-target <value>
    echo The value: $($@_value)

This way you can just use res := $(call fetch_parameter) on any target you want to retrieve values from.

Note: I've added an extra : on this bit of code $(eval $($(varname))::;@:) because if you have more than one target with a call to fetch_parameter it will also be triggered.
So if you have:

my-target: res := $(call fetch_parameter)
my-target: ## Example target. Usage: make my-target <value>
    echo The value: $($@_value)

my-target2: res := $(call fetch_parameter)
my-target2: ## Example target. Usage: make my-target2 <value>
    echo The value: $($@_value)

and you call make my-target2 hello, the way Make works, both $(call fetch_parameter) will be triggered causing the creation of 2 bogus hello targets, but with the extra : (hello::) Make won't complain that you are overriding a target.

Answer 13

I found a way to get the arguments with an equal sign =! The answer is especially an addition to @lesmana 's answer (as it is the most complete and explained one here), but it would be too big to write it as a comment. Again, I repeat his message: TL;DR don't try to do this!

I needed a way to treat my argument --xyz-enabled=false (since the default is true), which we all know by now that this is not a make target and thus not part of $(MAKECMDGOALS).

While looking into all variables of make by echoing the $(.VARIABLES) i got these interesting outputs:

[...] -*-command-variables-*- --xyz-enabled [...]

This allows us to go two ways: either getting all starting with a -- (if that applies to your case), or look into the GNU make specific (probably not intended for us to use) variable -*-command-variables-*-. ** See footer for additional options ** In my case this variable held:

--xyz-enabled=false

With this variable we can combine it with the already existing solution with $(MAKECMDGOALS) and thus by defining:

# the other technique to invalidate other targets is still required, see linked post
run:
    @echo ./prog $(-*-command-variables-*-) $(filter-out $@,$(MAKECMDGOALS))`

and using it with (explicitly mixing up order of arguments):

make run -- config --xyz-enabled=false over=9000 --foo=bar show  isit=alwaysreversed? --help

returned:

./prog isit=alwaysreversed? --foo=bar over=9000 --xyz-enabled=false config show --help

As you can see, we loose the total order of the args. The part with the "assignment"-args seem to have been reversed, the order of the "target"-args are kept. I placed the "assignment"-args in the beginning, hopefully your program doesn't care where the argument is placed.

---

following make variables looks promising as well:

MAKEFLAGS =  -- isit=alwaysreverse? --foo=bar over=9000 --xyz-enabled=false
MAKEOVERRIDES = isit=alwaysreverse? --foo=bar over=9000 --xyz-enabled=false

Answer 14

It's been for a while, but I'll provide mine version which I use in production.

I'll hope that someone will find it useful.

Example:

.PHONY: greeting
greeting:
    echo $(if $s,$s,)

Command:

make greeting s="hello world"

Output:

hello world

Answer 15

Another trick I use is the -n flag, which tells make to do a dry run. For example,

$ make install -n 
# Outputs the string: helm install stable/airflow --name airflow -f values.yaml
$ eval $(make install -n) --dry-run --debug
# Runs: helm install stable/airflow --name airflow -f values.yaml --dry-run --debug