xmake can also easily write some lua scripts to dump the build dependency graph https://github.com/xmake-io/xmake
Proposal to add build graph output to GNU Make (2020)
31–40 of 40 posts
Re: Proposal to add build graph output to GNU Make (2020)
#32Well there is makefile2graph https://github.com/lindenb/makefile2graph . It is even packaged be Debian and it does exactly that. I use it like this from inside the Makefile: make-db.png: make -f $(MAKEFILE) -Bnd | sed -e 's,$(MAKEDIR)/,,g' | make2graph | dot -Tpng -o $@ but with some gymnastics in order to remove very long path names (MAKEDIR) can be used from the shell directly.
Re: Proposal to add build graph output to GNU Make (2020)
#33Considering 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.
My bugbear with make (and even the better remake) is finding out why things are not happening. "No rule to make target" is such an uninformative error message. Could it not identify rules which would make the target were they not failing?
Re: Proposal to add build graph output to GNU Make (2020)
#34I have found the `--debug=v` flag to be super helpful for debugging make targets. The `v` flag generates a lot more output than `--debug` with no arguments. Would also love a graph though
Re: Proposal to add build graph output to GNU Make (2020)
#35Ive 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.
There's a couple of interactive graph visualization software out there that could be used instead of static dot file generation.
(One of the advantages of DOT is that it's a pretty common de facto standard for describing graphs, so you can import it into most graph manipulation libraries and mangle it further using that.)
Re: Proposal to add build graph output to GNU Make (2020)
#36I once helped maintain a nearly full featured implementation of make in Python (pymake) that grew out of the Firefox project. As much as I would like to support efforts like this, I feel like it is ultimately doomed to suffer from usability limitations because make does not have a static DAG. Rather, the DAG evolves dynamically as make evaluates targets. There are pesky problems like $(call) and $(eval) where you can…
This must be why after 45 years make still has no "list targets" option.
Re: Proposal to add build graph output to GNU Make (2020)
#37Ive 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.
[Noting that you said GUI, and what I'm about to say isn't]
There's a lot more to Graphviz than just dot, as it comes with some really good filtering tools that people often seem to miss. You can achieve an awful lot with just bcomps/ccomps. And, when you're running queries gc is useful to see that you're heading down the right path.
Re: Proposal to add build graph output to GNU Make (2020)
#38Earlier quoted context omitted.
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.
[Noting that you said GUI, and what I'm about to say isn't] There's a lot more to Graphviz than just dot, as it comes with some really good filtering tools that people often seem to miss. You can achieve an awful lot with just bcomps/ccomps. And, when you're running queries gc is useful to see that you're heading down the right path.
Yes, that could also be helpful to split a complicated build graph into more manageable pieces. I had a look at the tools available for an unrelated project a while ago; I probably need to see what’s available now. Hopefully the tools have progressed a bit.
Re: Proposal to add build graph output to GNU Make (2020)
#39You can hack some of this functionality into GNU Make makefiles by modifying $(SHELL). https://www.cmcrossroads.com/article/tracing-rule-execution-...
Clever hack!
Re: Proposal to add build graph output to GNU Make (2020)
#40Some 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…
AFAIK, Soong -> Bazel - https://blog.bazel.build/2020/11/12/aosp_migrating_to_bazel.... (2020)