I am working on a boot project. In my boot root directory there is a makefile that contains among other things, the following code which confuse me:
.DEFAULT_GOAL = all
.PHONY: all
all: xboot
xboot: $(TOP_DIR)/boot
#echo "Building Boot" $(TOP_DIR)
$(MAKE) -C $(TOP_DIR)/boot/src
Now, the problem is, that any time when this makefile is executed by calling make, the xboot receipt is always running. It seems that this xboot target acts like a phony target. From GNU Documentation regarding phony targets:
Phoniness is not inherited: the prerequisites of a phony target are
not themselves phony, unless explicitly declared to be so.
Means that xboot target is not a phony one, but it's receipt is always running. I could not find anywhere an explanation for that.
Project facts-
directory $(TOP_DIR)/boot contains sources and headers under $(TOP_DIR)/boot/src and $(TOP_DIR)/boot/include, directory $(TOP_DIR)/boot does not get touched at the build (it is not get updated)
Trying to understand the behavior I played around-
I tried touching $(TOP_DIR)/boot, and/or tried touching and creating file xboot file anywhere in the project, but behavior remains the same.
GNU Make 4.1
Built for x86_64-pc-linux-gnu
make is not always handling folder dependencies the way you expect.
Should use a file dependency inside $(TOP_DIR)/boot like $(TOP_DIR)/boot/.exists or, even better, all your source files with a $(wildcard ...) function.
Like:
xcode: $(widcard $(TOP_DIR)/boot/src/*.c $(TOP_DIR)/boot/src/*.h)
This will cause a rebuild only on code change.
Related
I have huge code base that includes huge number of makefiles. I am trying to understand the flow. For that i am running make command with debug flags (--debug=basic) to get the information like what is the order of targets being executed.
build command:- make --debug=basic release
Here is the debug info:-
File 'release' does not exist.
Must remake target 'release'.
File 'all' does not exist.
File 'copy_exports_files' does not exist.
File '/test/sw/modules/bin/ctk' does not exist.
Must remake target '/test/sw/modules/bin/ctk'
...
I can see flow of the targets being triggered. But I want to understand from which makefile the target is being triggered. Is there a way to log that info? Because its been hard to find where one makefile include other and soo on.
Thanks!
Try make --debug=verbose release
A question regarding "sentinels" in included make files.
I've inherited a project with a hierarchy of gmake projects, which uses make recursively. Due to the structure of the project, some files are included multiple times (once for each use of recursive gmake). These files are nothing fancy. Just variable definitions with some very basic if-logic. No recipes or dependencies. No nested includes.
The multiple-inclusion creates maintenance headaches. E.g. One can't use += in these files. I'd like to block multiple inclusions.
Putting a sentinel in the included files is the obvious solution, e.g.
ifeq ($(FOO_INCLUDED),)
FOO_INCLUDED=yes
else
# everything else
endif
But .... adding such a sentinel makes some recipes disappear in some sub-projects. E.g. a "build" target might disappear, while the "clean" target for the same sub-project doesn't. Make reports no egregious errors - it does attempt to run things. It just reports a missing target.
So the question is ... what could cause recipes being lost?
Restructuring to avoid the multiple includes is unfortunately not an option. Each sub-project is supposed to be buildable from either it's own folder (cd sub-project ; gmake build), or from the root folder (cd proj-root ; gmake subproject_build)
In my current setting, I have some .mk that are automatically generated, over which I have no control. One of the rules defined in these files is clean.
The part of the code I am working on uses include to access variables from those .mk files. However, I'd like to have another rule clean to remove the files generated in the folder I am working on.
If I create a rule named clean, I get the warning
warning: overriding commands for target
Is there a way to "extend" clean, i.e., o make it run both the clean defined in those .mk files and my own clean?
Of course, I could create another rule other_clean and call the old clean. Or also I could do something like:
other_clean:
make clean
rm *.o
But I'd like to know if there is any functionality in make that allows me to "inherit" the recipe defined elsewhere into my own clean. I saw there are these things called double-colon rules, but I can't use them because the files I am including are automatically generated.
I am autotoolizing a library project, and this project has some example programs. I want the example programs to be distributed in the dist, but not installed.
Currently the demo programs are organized like thus:
src/*.cpp (library source)
include/*.h (library headers)
demos/demo.cpp (example program)
demos/RunDemo (script to run demo)
It is important that RunDemo be runnable after building the software, without requiring the "install" step.
So far I have been able to build the "demo" exectuable using a noinst_PROGRAMS target. However, after make in a VPATH build, the following is available:
build/src/.libs/libxxx.so (etc..)
build/demos/demo
As you can see, the RunDemo script needed to execute "demo" is not copied to the $(builddir). I have tried a few things, e.g., adding RunDemo to dist_noinst_SCRIPTS, as well as adding my own copy targets and trying to hook all.. no matter what I try, I always get the output,
$ make RunDemo
make: Nothing to be done for `../../../projects/demo/RunDemo'.
I seem to be unable to create a target in the builddir that says "if this file is not in the builddir, copy it from the srcdir."
Is this possible with automake?
You can make files accessible in the build tree after the ./configure step using the AC_CONFIG_LINKS macro (provided with autoconf) in your configure.ac script. It will create a symbolic link if possible, otherwise it will copy the file.
In your case it would look like
AC_CONFIG_LINKS([demos/RunDemo:demos/RunDemo])
From the autoconf manual:
Macro: AC_CONFIG_LINKS (dest:source..., [cmds], [init-cmds])
Make AC_OUTPUT link each of the existing files source to the
corresponding link name dest. Makes a symbolic link if possible,
otherwise a hard link if possible, otherwise a copy. The dest and
source names should be relative to the top level source or build
directory
Using dist_noinst_SCRIPTS is still necessary for the file to be distributed.
I need some help debugging a Makefile system. I have a rather huge Makefile dependency tree, actually the Android source makefile system.
At some point the build fails because a file is missing:
/bin/bash: out/host/linux-x86/bin/mkfs.ubifs: No such file or directory
The file mkfs.ubifs is supposed to be "build" during the make process, and indeed it works if I do:
make out/host/linux-x86/bin/mkfs.ubifs
The mkfs.ubifs is build, and everything is working, until I again clean everything and build from the beginning.
This indicates to me, that there is a missing dependency somewhere. So my question is, how do I go about debugging this? How do I discover exactly which target is missing a dependency? What options can I provide for make which will give me clues as to where the error is?
Any other suggestions will also be appreciated. Thanks. :)
Update
Using make -d provides quite a lot of output. How exactly do I determine from which make target (sourcefile and line) and error occurred?
Problem solved. It seems make -p was the most useful way to debug this problem:
-p, --print-data-base
Print the data base (rules and variable values) that results from
reading the makefiles; then execute as usual or as otherwise spec-
ified. This also prints the version information given by the -v
switch (see below). To print the data base without trying to
remake any files, use make -p -f/dev/null.
From that output it is relatively easy to determine which target was failing, and what dependency that should be included.
There is a discrepancy between target's prerequisites and its commands, that is, a dependency is not specified for a target. I don't think you can debug that using make means because make can't tell you that a dependency is missing.
However, you can try invoking make with -d switch. That is going to tell you which target it tries to build when it hits the missing file. The next step would be to find the rule for that target in the makefile and add the missing dependency.