Our great sponsors
-
makefile2graph
Creates a graph of dependencies from GNU-Make; Output is a graphiz-dot file or a Gexf-XML file.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Well 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:
> Modern NDK applications are supposed to use CMake and Android's own build system is based on Soong.
Soong build files are easy to parse and you can create an Unified Dependency Graph from them. That's what I did in BGraph [0] for security applications.
[0] https://github.com/quarkslab/bgraph
I would very much like this for https://github.com/NixOS/rfcs/pull/92
Ninja's "-d explain" is next to useless in a large build: It says what's dirty but it's hard to relate which dirty input caused which output to be re-built. At the beginning of your build you get pages & pages of "these things are dirty" and then it starts the actual build. Also, this "explain" output is printed before ninja has realised that a lot of those things aren't actually dirty (thanks to "restat").
I've been using this in my build system to make the explain output slightly more useful: https://github.com/ninja-build/ninja/pull/2067
It's just a quick hack that took me half a day (most of which was remembering how to C++ after 8 years...) but I think it makes "-d explain" much more useful.
Really, the "explain" implementation could do with an overhaul. I'd love ninja to serialise the build graph to disk (or maybe just the subset of the graph that actually needed rebuilding). This could be augmented with the reason why each rule was run, and possibly even with the command output for each rule. Then the existing ninja tools like "graph", "browse", and "query" could optionally use this graph instead of the "build.ninja" file, so that you can inspect what happened the last time you ran "ninja".
Realistically I'll never get around to implementing this, and my pull request above gets me close enough.
xmake can also easily write some lua scripts to dump the build dependency graph https://github.com/xmake-io/xmake