I'm looking at existing makefiles and I see $(hide) but on the GNU Make docs, hide does not appear a single time.
What is $(hide)?
I suppose you meaning makefile(.mk) in Android building system.
Here's a older link that describe the usage.
By default, the $(hide) macro will hides the command executed on its line, if you want show command, set $(hide) to empty.
Related
GNU Make under MinGW is known to be very slow under certain conditions due to how it executes implicit rules and how Windows exposes file information (per "MinGW “make” starts very slowly").
That previous question and all other resources on the issue that I've found on the internet suggest working around the problem by disabling implicit rules entirely with the -r flag. But is there another way?
I have a "portable" Makefile that relies on them, and I'd like to make it so that it does not take around a minute to start it up each time, rather than having to get the Makefile owner to alter it just for me.
You should use make -d to see all the things make is doing and try to see where the time is going. One common reason for lengthy make times are match-anything rules which are used to determine whether or not a makefile needs to be rebuilt. Most of the match-anything rules CAN be removed; they're rarely needed anymore.
You can add this to your makefile and see if it helps:
%:: %,v
%:: RCS/%,v
%:: RCS/%
%:: s.%
%:: SCCS/s.%
And, if you don't need to auto-create your makefile you can add:
Makefile: ;
(also put any included makefiles there that you don't need to auto-create).
ETA
It seems your real question can be summed up as, "why does make take so much longer to start on Windows than on Linux, and what can I do to fix that without changing makefiles?"
The answer is, nothing. Make does exactly the same amount of work on both Windows and Linux: there are no extra rules or procedures happening on Windows that could be removed. The problem is that Windows NTFS is slower than typical Linux filesystems for these lookups. I know of no system setting, etc. that will fix this problem. Your only choice is to get make to do less work so that it's faster, and the only way to do that is by removing built-in rules you don't need.
If the problem is you really don't want to edit the actual makefiles, that's simple enough to solve: just write the rules above into a small separate makefile, maybe something like speedup.mk, then set the environment variable MAKEFILES=speedup.mk before invoking make. Make will parse that makefile as well without you having to change any makefiles.
I would like to get a list of prerequisites that make would use to create/update its targets. This would be used to gather a list of source files to feed into a static analysis tool. I could do something like Clang's scan-build does and override the compiler variable with a shell script that appends to a file or something, but I was wondering if there is a more elegant solution.
I believe your choices are:
do like scan-build does
parse the output from make -qp (possibly -np I'm not sure).
parse make yourself
in descending order of simplicity/ease (assuming you want to build at the same time).
If you don't want to require actually building then I believe item one cycles to the bottom of the order.
remake may also be of use here though I don't recall offhand.
So I have a script, myscript.py, that produces a few output files, out/a.pickle, out/b.pickle, and out/c.pickle
And I have a Makefile that has the rule:
out/a.pickle: data/data.csv
myscript.py
Now, If I update the script, firstly, make out/a.pickle says there's nothing to be done here, even though the script has been modified. Isn't make supposed to check to see if things have been updated and then run them? Do I need to add myscript.py as a dependency to out/a.pickle, or something?
Secondly, is there a way to handle the fact that the script has multiple output files? Do I need to create a rule for each?
Make does not examine time stamps on executables. Otherwise, you would have to recompile the universe if gcc or echo or the shell is upgraded, and it's a slippery slope anyway; what if libraries or the kernel also changed in a way which requires you to recompile? You need human intervention at some point anyhow. So the designers of make simply drew the line at explicit dependencies.
(GNU Make has a lot of other built-in implicit dependencies, which are convenient. I vaguely believe that the original make didn't have any built-in dependencies at all. Anybody able to confirm?)
You can declare all the outputs in one rule:
out/a.pickle out/b.pickle out/c.pickle: myscript.py data/data.csv
./$^
(Notice how the script is included in the dependencies now. You might want to change that after the script is considered stable. Then you'll need to change the action as well.)
Can somebody please enlighten me as to what the command line flag to CMake might be that will make it print out all the compile/link commands it executes?
I can't find this anywhere in the documentation. Many hours of my life have just evaporated. I'd just like to verify it's doing what I think it is, (then banish the infernal build system altogether and replace it with a GNU Makefile).
Thank you!
The verbose argument should do what you want.
Content copied (with format adjusted slightly) here for future reference:
CMake/Verbose output
CMake has a nice colored output which hides the commandline. This is pretty to look at in the long run but sometimes when you write your configurations you want to know if you got all the compiler flags right. There is two ways to disable the pretty output, well, it's essentialy the same but still two different ways.
The first way is to simply run make with the additional argument "VERBOSE=1". This will show each command being run for this session, which is the most useful way to see if the flags is correct:
make VERBOSE=1
The second way is to permanently disable the pretty output in your CMakeLists.txt by setting CMAKE_VERBOSE_MAKEFILE:
set( CMAKE_VERBOSE_MAKEFILE on )
Content is available under Attribution-ShareAlike 2.5 unless otherwise noted.
Setting CMAKE_VERBOSE_MAKEFILE Works but the generator must be make. Documentation seems to assume this the case. Should probably be explicitly noted there.
In bash, I believe it is possible to enable tab completion on the terminal for terms that are specific to the executable being invoked.
For example, given an executable "eat" with valid arguments {cake, carrot, banana}, typing 'eat car' should complete to 'eat carrot'.
I believe this is possible because I have seen it with 'ant' tab-completing its targets (though how this was set up I don't know).
How can this behaviour be implemented?
This is done with scripts in /etc/bash_completion.d/ and if you want to write your own completion support for an executable, here's a tutorial to get you started.
If you only need to get the behaviour working for common executables, your Linux distro probably has a bash-completion package available with support for common commands.
This is quite similar to filename globbing where the shell will attempt to autocomplete based on the globbing wildcard...for instance....
echo foo*
will list all files in the current directory beginning with 'foo'...the bash shell globbed the wildcard and expanded it into a list of files...
MSDOS had a similar concept, although it was not explicitly linked in at run-time, I'm talking about the old Turbo C stuff, when the wildcard globbing was activated by linking with 'wildargs.obj' (if my memory serves me correct), internally, that code will iterate through the directory and expand the list based on wildcard pattern matching.
In Linux/*nix land, globbing is standard, but however, you cannot manually hit the sequence Tab key to do the pattern matching or completion...as different terminals may translate the tab key differently and of course handle it differently...