<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>indygreg2</author><text>I once helped maintain a nearly full featured implementation of make in Python (pymake) that grew out of the Firefox project.&lt;p&gt;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 dynamically inject make expressions into a partially evaluated DAG. And targets can generate files which are later loaded via include directives.&lt;p&gt;Dumping the make database in a machine readable format (for visualization or otherwise) would be incredibly valuable for debugging and could improve understanding. But since many make files have N&amp;gt;&amp;gt;1 &amp;quot;snapshots&amp;quot; of the internal DAG during their execution, there is a really thorny problem around when and which of these &amp;quot;snapshots&amp;quot; to use and how to stitch them together. Many make files aren&amp;#x27;t &amp;quot;static&amp;quot; enough to support exporting a single, complete, and valuable usable snapshot of their internal DAG.&lt;p&gt;If debugging is the target goal, I think a potentially better approach would be to define a function that takes an output filename and optional list of targets and writes out the point-in-time build graph when that function is called. This way makefile authors could insert probes in the make file (including at the bottom of a make file so the function is called on file load) and capture the state(s) of the build graph exactly when they need to. There could also be a specially named variable holding the names of targets that when pre- or post-evaluated would trigger the dumping of the database.&lt;p&gt;Best of luck to the person doing this work. Debugging make is notoriously hard and any progress in this area will be much welcomed by its many users.</text><parent_chain></parent_chain></comment><story><title>Proposal to add build graph output to GNU Make (2020)</title><url>http://jonasdn.blogspot.com/2020/10/proposal-to-add-build-graph-output-to.html</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>vasvir</author><text>Well there is makefile2graph &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;lindenb&amp;#x2F;makefile2graph&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;github.com&amp;#x2F;lindenb&amp;#x2F;makefile2graph&lt;/a&gt;. It is even packaged be Debian and it does exactly that.&lt;p&gt;I use it like this from inside the Makefile:&lt;p&gt;&lt;pre&gt;&lt;code&gt;  make-db.png:       
      make -f $(MAKEFILE) -Bnd | sed -e &amp;#x27;s,$(MAKEDIR)&amp;#x2F;,,g&amp;#x27; | make2graph | dot -Tpng -o $@
&lt;/code&gt;&lt;/pre&gt;
but with some gymnastics in order to remove very long path names (MAKEDIR) can be used from the shell directly.</text><parent_chain></parent_chain></comment><story><title>Proposal to add build graph output to GNU Make (2020)</title><url>http://jonasdn.blogspot.com/2020/10/proposal-to-add-build-graph-output-to.html</url></story>