Proposal to add build graph output to GNU Make (2020)
jonasdn.blogspot.com
Proposal to add build graph output to GNU Make (2020)
1–10 of 40 posts
Re: Proposal to add build graph output to GNU Make (2020)
#2Some clarification needed,
> The Android build system works by including all recipes to be built (programs / libraries / etc) using the GNU Make include directive, so that you end up with one giant Makefile that holds all rules for building the platform. Possibly to avoid the problems laid out in the paper Recursive make considered harmful.
The old build system (ndk-build) works like this.
Modern NDK applications are supposed to use CMake and Android's own build system is based on Soong.
Re: Proposal to add build graph output to GNU Make (2020)
#3This would be quite useful. We have a couple of large-ish projects with a couple of hundreds files compiled in parallel and there are snags every now and then (which disappear when re-running make either in parallel or sequential modes). Getting a graph in these cases would be a nice time saver.
I’ll try the fork.
Re: Proposal to add build graph output to GNU Make (2020)
#4Considering that all build systems must keep a dependency graph internally, it’s surprising how many of them make it incredibly difficult to inspect why things are being rebuilt. I don’t really get it either, I’ve talked to a lot of people and getting feedback on how the build system is doing its task is one of the biggest complaints I see (others are “what is the build system doing” and “why does this have the worst syntax and weird edge cases”) and I mean all the build tools have literally everything they need to show this externally, but basically none expose it in a reasonable manner (if at all). I should be able to go, “oh you rebuilt all of libFoo.a because I accidentally made it depend on autogenerated.cpp”. If you are making a new build system today (and I am sure some of you here are considering it :P) please make this one of your priorities when designing the tool.
Re: Proposal to add build graph output to GNU Make (2020)
#5Considering that all build systems must keep a dependency graph internally, it’s surprising how many of them make it incredibly difficult to inspect why things are being rebuilt. I don’t really get it either, I’ve talked to a lot of people and getting feedback on how the build system is doing its task is one of the biggest complaints I see (others are “what is the build system doing” and “why does this have the worst…
GNU Make is pretty good about telling you why things are happening with -d
If you can get away with it use -rR to skip builtins, it makes the output of -d much nicer.
I usually end up running make with -rRd or -rRp when I want to inspect things. -d tells you why things happen and -p shows you what rules and variables are defined.
Re: Proposal to add build graph output to GNU Make (2020)
#6You can hack some of this functionality into GNU Make makefiles by modifying $(SHELL).
https://www.cmcrossroads.com/article/tracing-rule-execution-...
Re: Proposal to add build graph output to GNU Make (2020)
#7See also: https://github.com/rocky/remake
ISTR there was a thread about it here a few months ago.
Re: Proposal to add build graph output to GNU Make (2020)
#8Ive tried this before but with a complex build the graph is unwieldy and useless
Re: Proposal to add build graph output to GNU Make (2020)
#9Considering that all build systems must keep a dependency graph internally, it’s surprising how many of them make it incredibly difficult to inspect why things are being rebuilt. I don’t really get it either, I’ve talked to a lot of people and getting feedback on how the build system is doing its task is one of the biggest complaints I see (others are “what is the build system doing” and “why does this have the worst…
Like
ninja -d explain
?Re: Proposal to add build graph output to GNU Make (2020)
#10Ive tried this before but with a complex build the graph is unwieldy and useless
It’s probably more suited for the OP’s use case (a couple of files causing some re-building) because otherwise yeah, the build tree can be humongous.
That said, isn’t there some software to visualise dot files in a more sophisticated way than just generating a picture? It would be handy to be able to collapse/expand sub graphs in a GUI, for example.