I am trying to run a recursive invocation of "question mode", and I get an error in a very unique scenario.
I am using MAKE 3.81, and this has been tested on two completely separate environments.
I call "make -q", then that makefile calls "$(MAKE) -C sub/a/", then that makefile calls "$(MAKE) -f ../../makefile.b"
The testcase is as simple as I can make it. Can someone tell me why I get this error:
nachum:/home/nachum/makefile_bug[1497]$make -q
make -C sub/a
make[1]: Entering directory `/home/nachum/makefile_bug/sub/a'
make -f ../../makefile.b
make[1]: *** [b] Error 1
make[1]: Leaving directory `/home/nachum/makefile_bug/sub/a'
make: *** [a] Error 2
nachum:/home/nachum/makefile_bug[1498]$
Here are the makefiles:
makefile:
a:
$(MAKE) -C sub/a
sub/a/makefile:
b:
$(MAKE) -f ../../makefile.b
makefile.b:
all:
echo hi
The whole point of this exercise is to be able to check if sub projects need to be recompiled so I can properly build the top level project when necessary. Otherwise I have to use timestamps for everything. (I previously used timestamps, but I realized that caused extra confusion for other things.)
There are some weird workarounds for this problem. For example, if the recipe for a (in makefile) has an additional line above the call to $(MAKE), ie:
makefile:
a:
#echo hi
$(MAKE) -C sub/a
The problem goes away, AND the dependencies (in my full testcase) still work. Also using make directly seems to change the behavior (as opposed to $(MAKE)).
Any help would be appreciated.
Thanks,
Nachum
Your problem is roaming around the -q option specified. -q would run no command but give exit status if up to date. When you use ${MAKE} make -q -C sub/a is executed. after little permutation and combination I found that we can't use -q with -C option. If you want quite then use make --quite or if you just want to check the timestamps then try with -t (touch but don't compile) or '-n` (dry run).
Related
I would like to check if a file exists in a Makefile and run a recipe if it doesn't exist and stop after creating it else continue working with the file that exists and execute more recipes. I think this is best illustrated with an example in my Makefile:
GEN_C_FILES: GEN_C_FLS
$(shell cat $(DESIGN_TOP).c.tmp c_template.c.tmp > $(DESIGN_TOP).c )
$(DESIGN_TOP).c:
$(MAKE) GEN_C_FILES
#(echo $(DESIGN_TOP).c created and modify it to suit the design before running COMPILE)
exit 1
COMPILE: $(DESIGN_TOP).c
#(echo bsub -I compile_script-batch $(DESIGN_TOP).c -log $(DESIGN_TOP).log)
#(bsub -I compile_script -batch $(DESIGN_TOP).c -log $(DESIGN_TOP).log)
I can accomplish what I want but the exit produces an error message. I want it to exit if the recipe of $(DESIGN_TOP).c is executed but if the recipe is not executed the file exist and so it need not be generated and the rest of COMPILE target should complete by running the compile on bsub. Is there a better way to accomplish this without generating the error on exit?. Thanks
You can't make it work as you want when running make COMPILE. The only way to get make to stop in the middle of a build process and not proceed any further is to fail. But, instead you can change what make wants to build in the first place, like this:
GOAL = $(if $(wildcard $(DESIGN_TOP).c),COMPILE,$(DESIGN_TOP).c)
all: $(GOAL)
$(DESIGN_TOP).c:
cat $(DESIGN_TOP).c.tmp c_template.c.tmp > $#
#echo $# created and modify it to suit the design
COMPILE: $(DESIGN_TOP).c
bsub -I compile_script -batch $< -log $(DESIGN_TOP).log
Now if you run make or make all and the source file does not exist, the prerequisite of all will be the source file and nothing else, so it will be built then make will stop.
If the source file does exist, then the prerequisite of all will be COMPILE and it will be built.
after make's Makefile did flawlessly and next it was renamed to Makefile_
then it's run by the exact command but being inserted with:
-f Makefile
so now
make -f Makefile_ (... the rest identical),
then went out to give :
make[1]: Nothing to be done for 'all'
How'd it mean and be solved ?
Makefiles are intelligent and only compile or recompile when necessary, for example if a change in the files has been detected.
So if you've altered your code and then ran your Makefile, it will compile the corresponding code. But if you run it again without changing anything, it will give you an error message saying that there isn't anything to be done.
Thus the message:
make[1]: Nothing to be done for 'all'
If you want to avoid this, you can change a small part of your code just to recompile it or use the -B flag to force a remake.
With the -B flag, the command would be:
make -f Makefile_ -B
I want make to continue even if a dependency's build fails. I usually use -i to accomplish this. A colleague of mine said he uses -k. Indeed, this stack overflow question has an answer for each:
Make: how to continue after a command fails?
Is there a difference between these two options?
Here's what the make man page says for these two options:
-i, --ignore-errors
Ignore all errors in commands executed to remake files.
-k, --keep-going
Continue as much as possible after an error. While the
target that failed, and those that depend on it, cannot be
remade, the other dependencies of these targets can be
processed all the same.
What -k describes is what I think -i does. I'm sure I'm missing something: can someone help me understand the difference?
Consider this makefile:
all: fail success
all success:
#echo $#
fail:
exit 1
#echo $#
Now run with the two flags:
$ make -i
exit 1
make: [Makefile:7: fail] Error 1 (ignored)
fail
success
all
This flag caused make to pretend that a specific recipe command succeeded, even though it failed. Thus the all target is still run, because make believes that the fail target actually succeeded. It's equivalent to adding a - at the beginning of every recipe line.
As opposed to:
$ make -k
exit 1
make: *** [Makek:7: fail] Error 1
success
make: Target 'all' not remade because of errors.
Here, make knows the fail target was not built. success is run because of -k: it doesn't depend on fail. However, all is not built because it does depend on fail.
I've never really needed -i; it seems dangerous to me.
On the other hand, I use -k almost by default.
From the docs:
Usually when a recipe line fails, if it has changed the target file
at all, the file is corrupted and cannot be used--or at least it is not
completely updated. Yet the file's time stamp says that it is now up to
date, so the next time 'make' runs, it will not try to update that file.
The situation is just the same as when the shell is killed by a signal;
*note Interrupts::. So generally the right thing to do is to delete the
target file if the recipe fails after beginning to change the file.
'make' will do this if '.DELETE_ON_ERROR' appears as a target. This is
almost always what you want 'make' to do, but it is not historical
practice; so for compatibility, you must explicitly request it.
So, here I have a makefile:
# The idea here is to auto-generate the file ('make.include')
# and to use it as a makefile.
# For simplicity, I replaced the "auto-generate" part, with "touch".
# I also simplified the dependency-tree with 'phony'.
# In practice, we re-generate, only when "need" to.
make.include : phony
+touch '$#'
make -f '$#'
.PHONY: phony
Running:
$ make -q
I get:
touch 'make.include'
make: *** Deleting file 'make.include'
Now, i don't see how to prevent make from deleting this newly auto-generated 'make.include' (which may well be quite a costly process to re-run), unless i resort to the .PRECIOUS special target.
But, demanding the user to explicitly define their "precious" targets, is not in-line with that quote from the docs above. Right?
This arises because of your use of + in +touch '$#' and executing make with the -q option. From the GNU Make Manual the -q option is
“Question mode”. Do not run any recipes, or print
anything; just return an exit status that is zero if the specified
targets are already up to date, one if any remaking is required, or
two if an error is encountered. See Instead of Executing Recipes.
The + symbol is only relevant when make is executed with the -t, -n or -q options and it tells make to execute any commands it precedes make is executed with any of the options -t, -n or -q. So, when you execute your current makefile with make -q you are asking make to check if everything is up to date without running any commands but because you've specified + before touch '$#' make must execute this command. To then leave everything the way it was before you executed make -q make must delete the file it created with +touch '$#'.
To answer your question specifically. If you don't want make to delete make.include then you can run make without the -q option on the makefile specified in your question.
However, the recipe for a target, i.e. make.include should not call its self with make -f make.include. It would probably be better to rewrite the makefile so that the recipe for make.include only creates make.include and it is then called with make -f make.include in another recipe.
make.include:
+touch $#
all: make.include
make -f $<
I'm trying to debug a compilation problem, but I cannot seem to get GCC (or maybe it is make??) to show me the actual compiler and linker commands it is executing.
Here is the output I am seeing:
CCLD libvirt_parthelper
libvirt_parthelper-parthelper.o: In function `main':
/root/qemu-build/libvirt-0.9.0/src/storage/parthelper.c:102: undefined reference to `ped_device_get'
/root/qemu-build/libvirt-0.9.0/src/storage/parthelper.c:116: undefined reference to `ped_disk_new'
/root/qemu-build/libvirt-0.9.0/src/storage/parthelper.c:122: undefined reference to `ped_disk_next_partition'
/root/qemu-build/libvirt-0.9.0/src/storage/parthelper.c:172: undefined reference to `ped_disk_next_partition'
/root/qemu-build/libvirt-0.9.0/src/storage/parthelper.c:172: undefined reference to `ped_disk_next_partition'
collect2: ld returned 1 exit status
make[3]: *** [libvirt_parthelper] Error 1
What I want to see should be similar to this:
$ make
gcc -Wall -c -o main.o main.c
gcc -Wall -c -o hello_fn.o hello_fn.c
gcc main.o hello_fn.o -o main
Notice how this example has the complete gcc command displayed. The above example merely shows things like "CCLD libvirt_parthelper". I'm not sure how to control this behavior.
To invoke a dry run:
make -n
This will show what make is attempting to do.
Build system independent method
make SHELL='sh -x'
is another option. Sample Makefile:
a:
#echo a
Output:
+ echo a
a
This sets the special SHELL variable for make, and -x tells sh to print the expanded line before executing it.
One advantage over -n is that is actually runs the commands. I have found that for some projects (e.g. Linux kernel) that -n may stop running much earlier than usual probably because of dependency problems.
One downside of this method is that you have to ensure that the shell that will be used is sh, which is the default one used by Make as they are POSIX, but could be changed with the SHELL make variable.
Doing sh -v would be cool as well, but Dash 0.5.7 (Ubuntu 14.04 sh) ignores for -c commands (which seems to be how make uses it) so it doesn't do anything.
make -p will also interest you, which prints the values of set variables.
CMake generated Makefiles always support VERBOSE=1
As in:
mkdir build
cd build
cmake ..
make VERBOSE=1
Dedicated question at: Using CMake with GNU Make: How can I see the exact commands?
Library makefiles, which are generated by autotools (the ./configure you have to issue) often have a verbose option, so basically, using make VERBOSE=1 or make V=1 should give you the full commands.
But this depends on how the makefile was generated.
The -d option might help, but it will give you an extremely long output.
Since GNU Make version 4.0, the --trace argument is a nice way to tell what and why a makefile do, outputing lines like:
makefile:8: target 'foo.o' does not exist
or
makefile:12: update target 'foo' due to: bar
Use make V=1
Other suggestions here:
make VERBOSE=1 - did not work at least from my trials.
make -n - displays only logical operation, not command line being executed. E.g. CC source.cpp
make --debug=j - works as well, but might also enable multi threaded building, causing extra output.
I like to use:
make --debug=j
https://linux.die.net/man/1/make
--debug[=FLAGS]
Print debugging information in addition to normal processing. If the FLAGS are omitted, then the behavior is the same as if -d was specified. FLAGS may be a for all debugging output (same as using -d), b for basic debugging, v for more verbose basic debugging, i for showing implicit rules, j for details on invocation of commands, and m for debugging while remaking makefiles.
Depending on your automake version, you can also use this:
make AM_DEFAULT_VERBOSITY=1
Reference: AM_DEFAULT_VERBOSITY
Note: I added this answer since V=1 did not work for me.
In case you want to see all commands (including the compiled ones) of the default target run:
make --always-make --dry-run
make -Bn
show commands executed the next run of make:
make --dry-run
make -n
You are free to choose a target other than the default in this example.