I am working on a complex make file that was written by other developers, this makefile also includes other makefiles.
I put a dumb rule at the beginning of the makefile, then invoked the makefile without specifying a target expecting that the first rule executes only (which echoes something), but I found that other rules got invoked.
I wonder is there any cases where other rules may get evaluated before the first rule (maybe because of includes or secondary expansions or others)?
The very first (non-pattern non-leading-dot) rule that make sees is the default target (by default). Whether that comes from the Makefile or some included makefile doesn't matter.
Additionally, a makefile can override that by setting the .DEFAULT_GOAL special variable.
This is discussed in the How make Processes a Makefile section of the GNU make manual.
By default, make starts with the first target (not targets whose names start with ‘.’). This is called the default goal. (Goals are the targets that make strives ultimately to update. You can override this behavior using the command line (see Arguments to Specify the Goals) or with the .DEFAULT_GOAL special variable (see Other Special Variables).
Related
In ffmpeg Makefile,
https://github.com/FFmpeg/FFmpeg/blob/master/Makefile#L37
https://github.com/FFmpeg/FFmpeg/blob/master/Makefile#L189
It defined phony targets "all" and "all-yes", but I can't find prerequisites and command of "all-yes" by searching whole ffmpeg directory. So can anyone help to explain what "all-yes" exactly means?
There is another "all" target in the "include $(SRC_PATH)/fftools/Makefile": https://github.com/FFmpeg/FFmpeg/blob/master/fftools/Makefile#L30
$(foreach P,$(AVPROGS-yes),$(eval $(call DOFFTOOL,$(P))))
all: $(AVPROGS)
fftools/ffprobe.o fftools/cmdutils.o: libavutil/ffversion.h | fftools
OUTDIRS += fftools
4.11 Multiple Rules for One Target
There can only be one recipe to be executed for a file. If more than one rule gives a recipe for the same file, make uses the last one given and prints an error message. (As a special case, if the file’s name begins with a dot, no error message is printed. This odd behavior is only for compatibility with other implementations of make… you should avoid using it). Occasionally it is useful to have the same target invoke multiple recipes which are defined in different parts of your makefile; you can use double-colon rules (see Double-Colon) for this.
There are two targets and make only uses the last one, so you could delete the "all-yes" or delete "all:all-yes" then use "make all" command, and it has no effect on the compilation. the command line "all:all-yes" is just ensure the "all" is the default target.
In our makefile, we have one recipe that links together all our object and library files to make an executable (an .elf file). As a side effect, this step also produces a map-file and an Intel .hex file:
$(ELF_FILE) : <list of dependencies here>
<linker command line>
Until now, since we never actually had a $(MAP_FILE) or a $(HEX_FILE) target, when ever another target depended on one of the $(ELF_FILE)'s side products, we simply declared it to be dependent on $(ELF_FILE), even if the recipe of that target didn't want to access the $(ELF_FILE) itself at all. For instance:
# Target that needs map-file, which is a side product of the $(ELF_FILE) target.
$(TARGET_THAT_NEEDS_MAP_FILE) : $(ELF_FILE)
<build-recipe>
# Target that needs hex-file, which is also a side product of the $(ELF_FILE) target.
$(TARGET_THAT_NEEDS_HEX_FILE) : $(ELF_FILE)
<build-recipe>
We have recently found out that a recipe can be used for more than one target, like so:
$(MAP_FILE) $(HEX_FILE) $(ELF_FILE) : <list of dependencies here>
<linker command line>
With this new-found knowledge, we figured we could get rid of the above "hack" and just directly state each target's direct dependencies:
$(TARGET_THAT_NEEDS_MAP_FILE) : $(MAP_FILE)
<build-recipe>
$(TARGET_THAT_NEEDS_HEX_FILE) : $(HEX_FILE)
<build-recipe>
Having implemented these changes, we now observe an odd effect that makes us suspect that we've either misunderstood this multiple-targets-one-recipe feature of make, or we're not using it correctly. The odd effect is that the recipe that produces the .elf, .map and .hex files now appears to run twice. This doesn't seem to have caused any immediate problems, but it does seem to indicate that something is fishy here. So my question, can our new approach work at all, or should we stick to the hack I described above?
EDIT: We're running our make in a multi-threaded manner (i.e. with -j).
It might be that when make is trying to update a target (whether it is $(MAP_FILE), $(HEX_FILE) or $(ELF_FILE), it does not know that its recipe will also update another target, therefore it starts a recipe for that one too, even if it's the same.
Of course, that would only happen when using the -j option. (Did you had the possibility to try without ?)
To illustrate :
$(TARGET): $(ELF_FILE) $(MAP_FILE)
<update target>
Here make will try to update $(ELF_FILE) and $(MAP_FILE) and fire the recipe twice. (That should also applies if the dependencies are on different target, as long as the targets are updated by a one execution of make and that there is no bottlenecks between them.
I'm not completely sure about that, though, make might be able to know that this is the same recipe.
======
This answer might be of use to you.
Specifically :
However, if your output files and your input file share a common base,
you CAN write a pattern rule like this:
%.foo %.bar %.baz : %.boz ; $(BUILDIT)
Strangely, for implicit rules with multiple targets GNU make assumes
that a single invocation of the recipe WILL build all the targets, and it will behave exactly as you want.
MadScientist
It refers to that part of the make manual :
Pattern rules may have more than one target. Unlike normal rules, this
does not act as many different rules with the same prerequisites and
recipe. If a pattern rule has multiple targets, make knows that the
rule’s recipe is responsible for making all of the targets. The recipe
is executed only once to make all the targets. When searching for a
pattern rule to match a target, the target patterns of a rule other
than the one that matches the target in need of a rule are incidental:
make worries only about giving a recipe and prerequisites to the file
presently in question. However, when this file’s recipe is run, the
other targets are marked as having been updated themselves.
EDIT:
Gnu Make has now gained a feature that would support this usecase (in version 4.3) : grouped explicit targets. It allows make to be aware that one recipe generate several targets, and it used like this (from the gnu make manual) :
foo bar biz &: baz boz
echo $^ > foo
echo $^ > bar
echo $^ > biz
foo, bar, and biz are generated by this rule (note the use of &: instead of :.
Full documentation : https://www.gnu.org/software/make/manual/html_node/Multiple-Targets.html ("Rules with Grouped Targets")
I am not aware of any way to define programatically targets in GNU Make. How is this possible?
Sometimes one can go away with alternate methods. The ability to define programatically targets in Makefiles is however a very important to write and organise complex production rules with make. Examples of complex production rules are found in the build system of FreeBSD or in Makefile libraries such as BSD Owl
The main differences between shell scripts and Makefiles are:
In a Makefile, the state of the program is given by the command line and the filesystem, so it is possible to resume a job after it has been interrupted. Of course, this requires to properly write the Makefiles, but even if this is rather hard, it is considerably easier than to achieve a similar effect with a shell script.
In a Makefile, it is ridiculously easy to decorate a procedure with advises or decorate it with hooks, while this is essentially impossible in shell scripts.
For instance, a very simple and useful pattern is the following:
build: pre-build
build: do-build
build: post-build
This presents the build target as a composite of three targets, one containing the actual instructions do-build and two other that are hooks, executed before and after do-build. This pattern is used by many build systems written for BSD Make, which incidentally allows programmatic definition of targets, so that one can write in a batch:
.for _target in configure build test install
.if !target(${_target})
${_target}: pre-${_target}
${_target}: do-${_target}
${_target}: post-${_target}
.endif
.endfor
The condition introduced by the .if/.endif block enables the user to use its own definition of any ${_target}.
What would be the translation of that snippet for GNU Make?
FWIW here is the make equivalent syntax for
.for _target in configure build test install
.if !target(${_target})
${_target}: pre-${_target}
${_target}: do-${_target}
${_target}: post-${_target}
.endif
.endfor
Basically, you want make to see something like this snippet:
build: pre-build
build: do-build
build: post-build
and similarly for configure, test and install. This suggests a loop with an eval somewhere:
define makerule =
$1: pre-$1
$1: do-$1
$1: post-$1
endef
targets := configure build test install
$(foreach _,${targets},$(eval $(call makerule,$_)))
(to play with this, change eval to info). Careful with those closures!
FWIW, here's the expansion of the foreach:
make expands the list to be iterated over
${targets} becomes configure, build, test and install
We have $(foreach _,configure build test install,$(eval $(call makerule,$_)))
_ is set to the first value, configure.
make expands $(eval $(call makerule,configure))
To evaluate the eval, make expands $(call makerule,configure)
It does this by setting 1 to configure, and expanding ${makerule} which produces 3 lines of text:
configure: pre-configure
configure: do-configure
configure: post-configure
$(eval) goes to work, reading this text as make syntax
Note that the expansion of the $(eval) is empty! All its work is done as a side effect.
Wash, lather, rinse, repeat.
Please note: I have to agree with all the other commenters: your pattern is bad make. If your makefile is not -j safe, then it is broken (missing dependencies).
First this structure is invalid if you ever want to support parallel builds; if you invoke make with the -j option it will run all three prerequisite rules at the same time, because while all of them must be complete before build, none of them depend on each other so there's no ordering defined (that is, you don't say that pre-build must be complete before do-build can run).
Second, GNU make has a number of facilities for programmatically defining rules. One thing GNU make does not have, currently, is the ability to search the targets which are already defined, so there's no direct analogy to .if !target(...).
However, you CAN search whether a variable has been defined or not using the .VARIABLES variable. So one workaround would be to define a variable if you want your own target and then have your rule generator check that.
I have a Variable in make that is dependant on a file that must be built before the variable can be set, is there a way to get this to work?
parsable_file: dependancies
commands to make parsable_file
targets=$(shell parse_cmd parsable_file)
$(targets): parsable_file
command to make targets
.phony: all
all:$(targets)
If I run $ make parsable_file && make all this will work (I get an error that parse_cmd cant find parsable_file but it works), but just make all will not work. Is there a Make idiom for this?
Set the variable in a file that you include in the main makefile and include a rule in the main makefile for how to build it (the one you already have should be fine).
I believe that will do what you want.
See Including Other Makefiles and How Makefiles Are Remade (which is linked from the first section) for more details on this concept.
Also, unless parseable_file has a usage independent from that parse_cmd call, it should be possible to do the creation and the parsing at the same time and just have the resulting makefile contain the correct value for $(targets) in one step.
How to pass the entire command line (including goals, link lines, make options etc) from top level make to recursive make:
targets : prerequisites
$(MAKE) $(this should expand to top level command line) additional_args
Thanks.
I think the closest you can get is using a combination of $(MAKE), which contains the exact filename make was invoked with, $(MAKECMDGOALS), which contains the goals you specified on the command line, and $(MAKEFLAGS), which contains any variable definitions and (a subset of) the switches specified on the command line.
The $(MAKE) macro is special and expands to include some relevant options. See the section How the MAKE variable works in the Make documentation for more details. However, this doesn't include the complete line including goals etc, and I'm not sure that is possible.
Usually I try to avoid using Make recursively, there's a good article about that here: Recursive Make Considered Harmful.