I have a Makefile, which fails at some point, with a git error. How can I view the git command that causes the whole make process to fail? More precisely, I am looking for a list of commands (including the ones that start with #) that I can run on an identical setup, to achieve the same effect as what make does.
I know for a script, instead of #! /bin/bash you would add a flag -x to it, and that would display all the commands before their execution. How do I do the same thing for make?
I am looking for a list of commands (including the ones that start with #) that I can run on an identical setup, to achieve the same effect as what make does.
By default, make echoes all recipe commands it runs, except those prefixed with #. The POSIX specifications for make do not describe a way to override that effect of # (but see below). It is conceivable that your make has an extension for that, but the make implementations you are most likely to be using (GNU make or BSD make, since you seem to assume that your standard shell is bash) do not.
Additionally, in POSIX-conforming make implementations, including the two mentioned above, the special target .SILENT can be used to suppress echoing the commands of some or all targets, and the -s command-line option can be used to suppress echoing for all targets.
You can print recipe commands prefixed with # if you run make with the -n (no-op) flag. That will print the commands for out-of-date targets without running them, except that those prefixed with a + are run even in no-op mode. Commands prefixed with # are included among those printed. Under some circumstances, the fact that most commands are not actually run in this mode can affect the output, but all the cases I can think of at the moment involve recursive make, and I think they are fairly unlikely.
POSIX seems to indicate that -n does not override -s or .SILENT, so if you have to deal with those then you may have no alternative but to modify your makefile. If you happen to be using GNU make, however, you will find that -n does override .SILENT and -s in that implementation. The same may be true of other makes.
Related
I'm working on a project which requires using make.
From the command like I run either make Release or make Debug.
However, there is not a makefile in the directory in which I run the make command.
How can I tell which makefile the make command is using?
In GNU make you can use the make variable MAKEFILE_LIST to inspect which makefile(s) were read; yes, there can be more than one due to multiple -f options and include directives.
If you need the name of the last read makefile, use $(lastword $(MAKEFILE_LIST)).
See also the GNU make manual.
GNU make has a debug option. If you use -d, make will print all debugging output.
The debug level can be changed with --debug[=FLAGS].
--debug=v should show you which makefiles were parsed.
GNU make manual:
v (verbose):
A level above ‘basic’; includes messages about which makefiles were parsed, prerequisites that did not need to be rebuilt, etc. This option also enables ‘basic’ messages.
See the man page for additional information.
I'm working on bash auto-completion for a project I'm the maintainer of. You can find the script here. I've cobbled this together with some hacking on my own, and with the help of some contributors who understand that completion APIs better than I do.
What we have works great -- with one exception. We can manage a completion like like this
//type
pestle.phar som[TAB]
//completes to
pestle.phar some-command-name
However, once we're here we lose file path/name completion that's a part of the stock bash shell. That is, working off the previous example, if a user types
//type
pestle.phar some-command-name /va[TAB]
we'd like it to complete to
//completes to the following, because var exists
pestle.phar some-command-name /var
Is there a way to just tell the complete command something like
Hey, in addition to everything we're telling you to do with our custom bash function, also keep your normal file path completion
If not, is there there some known science/boilerplate to reimplementing the file path completion in your own custom base completion functions?
Some other answers and the docs seem to indicate that the -o filenames or -o bashdefault options should take care of this -- but it doesn't seem to be working on OS X 10.11. I'm not sure if I misunderstand -o, or if the code in my completion files somehow overrides the -o behavior, or if OS X is doing it's I'm only a mostly well behaved unix thing.
Also -- if it's not obvious -- this is my first deep bash completion rodeo. If I've said something seemingly dumb/naive above please let me know. I may be looking for a fish right now, but I'd like to learn to fish in the bash completion river myself.
I think -o default (without -o filenames) should work for you. According to the manual:
bashdefault
Perform the rest of the default bash completions if the compspec generates no matches.
default
Use readline's default filename completion if the compspec generates no matches.
filenames
Tell readline that the compspec generates filenames, so it can perform any filename-specific processing (like adding a slash to directory
names, quoting special characters, or suppressing trailing spaces). Intended to be used with shell functions.
(Also see 'complete -d -o default cd' issue for the difference between -o default and -o bashdefault.)
I'm working a small JS project and trying to get a script to run, which compiles some source files that are written in our own "language x".
To run the compiler normally you would use the command ./a.out < source.x And it would print out success or compilation errors etc.
In the case now, I'm trying to working between two directories and using this command:
sudo ~/Documents/server/xCompiler/./a.out < ~/Documents/server/xPrograms/source.x
But this produces no output into the terminal at all and doesn't affect the output files. Is there somthing I'm doing wrong with the use of <? I'm planning to use it in child_process.exec within a node server later.
Any help would be appreciated, I'm a bit stumped.
Thanks.
Redirection operators (<, >, and others like them) describe operations to be performed by the shell before your command is run at all. Because these operations are performed by the shell itself, it's extremely unlikely that they would be broken in a way specific to an individual command: When they're performed, the command hasn't started yet.
There are, however, some more pertinent ways your first and second commands differ:
The second (non-working) one uses a fully-qualified path to the compiler itself. That means that the directory that the compiler is found in and the current working directory where the compiler is running can differ. If the compiler looks for files in or in locations relative to its current working directory, this can cause a failure.
The second uses sudo to escalate privileges to run the compiler. This means you're running as a different user, with most environment variables cleared or modified (unless explicitly whitelisted in /etc/sudoers) during the switch -- and has widespread potential to break things depending on details of your compiler's expectations about its runtime environment beyond what we can reasonably be expected to diagnose here.
That first one, at least, is amenable to a solution. In shell:
xCompile() {
(cd ~/Documents/server/xCompiler && exec ./a.out "$#")
}
xCompile < ~/Documents/server/xPrograms/source.x
Using exec is a performance optimization: It balances the cost of creating a new subshell (with the parenthesis) by consuming that subshell to launch the compiler rather than launching it as a subprocess.
Calling the node child_process.exec(), you can simply pass the desired runtime directory in the cwd argument, so no shell function is necessary.
I'm building a Makefile for a sequence of compiles to show progressive output differences to be used to synchronize with the examples in a tutorial. Some of those runs generates error codes, but since that is part of the definition of the "problem" the message output by make ("Makefile:15: recipe for target `run3' failed") when a target fails kind of gets in the way.
I know about ignoring the error code, but is it possible to suppress that output? Preferable from within the Makefile.
On a similar note, is it possible to suppress the message of entering and leaving subdirectories from within the Makefile (equivalent to '--no-print-directory')?
And, yes, I'm satisfied with a GNU Make answer.
Of course, after some googling the answer is in the GNU Make manual. The special targets .SILENT and .IGNORE did exactly what I wanted.
To achieve what you want I would use --silent --ignore-errors --no-print-directory GNU make switches and redirect stderr to /dev/null (2>/dev/null) commands in the makefile
Is there a way to log the commands, make invokes to compile a program? I know of the parameters -n and -p, but they either don't resolve if-conditions but just print them out. Or they don't work, when there are calls to 'make' itself in the Makefile.
This
make SHELL="sh -x -e"
will cause the shell (which make invokes to evaluate shell constructs) to print information about what it's doing, letting you see how any conditionals in shell commands are being evaluated.
The -e is necessary to ensure that errors in a Makefile target will be properly detected and a non-zero process exit code will be returned.
You could try to log execve calls with strace
strace -f -e execve make ...
Make writes each command it executes to the console, so
make 2>&1 | tee build.log
will create a log file named build.log as a side effect which contains the same stuff written to the screen. (man tee for more details.)
2>&1 combines standard output and errors into one stream. If you didn't include that, regular output would go into the log file but errors would only go to the console. (make only writes to stderr when a command returns an error code.)
If you want to suppress output entirely in favor of logging to a file, it's even simpler:
make 2>&1 > build.log
Because these just capture console output they work just fine with recursive make.
You might find what you're looking for in the annotated build logs produced by SparkBuild. That includes the commands of every rule executed in the build, whether or not "#" was used to prevent make from printing the command-line.
Your comment about if-conditions is a bit confusing though: are you talking about shell constructs, or make constructs? If you mean shell constructs, I don't think there's any way for you to get exactly what you're after except by using strace as others described. If you mean make constructs, then the output you see is the result of the resolved conditional expression.
Have you tried with the -d parameter (debug)?
Note that you can control the amount of infos with --debug instead. For instance, --debug=a (same as -d), or --debug=b to show only basic infos...