Follow-up Comment #4, bug #59318 (project make):
[comment #3 comment #3:]
> Hi!
>
> Nice proposal. The Remake project (http://bashdb.sourceforge.net/remake/)
already implements something like this. We even tried it on our project.'
Hi, thanks!
I just tried remake. The --profile option feels like a superset of this
function yes! Browsing the resulting graph via kcachegrind is a nice
experience!
>
> The problem I found with that feature is that the resulting graph can be
incomprehensibly large (millions of nodes for large projects) and therefore
not very useful in reality. In the end, we figured out that the easiest way to
ensure that we can identify why something is being remade is to add basic
logging to all make runs (--debug=b). This shows very minimal details, does
not distort the logs too much but provides the vital info required to identify
the root cause in most cases.
>
Yes, I agree with this. This feature might be most useful for finding out
result for specific targets or for smaller projects.
At least if you want to create a full graph and visualize it all at once.
Another way to go is what kcachegrind does, with the remake case. And another
tool that is taskexp (and depexp before it) in the Yocto project.
They allow you to search and browse targets, and follow certain paths that you
are interested in.
With an explorer using a well-thought UI you could create a nice experience
from a dot graph as well I believe.
> On the other hand, such a graph can be really useful to discover
dependencies and use it to optimize the build. Of course, that requires proper
tooling for the graph handling.
>
Agreed.
> Have you tried the Remake implementation? Did you find it useful in
practice?
I tried it for the first time tonight. I feel it could be useful!
I might say that an "advantage" with my implementation is that it is smaller
in ambition :) I tried to keep the code and the outputs as non-invasive as I
could. And I believe other tools could be used to interpret the resulting dot
graph.
Thanks for your comment!
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?59318>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
