Re: [PATCH] build: output a dependency log in build directory

[Bruce Richardson <bruce.richardson@intel.com>]

On Wed, Jul 31, 2024 at 11:17:54AM +0100, Ferruh Yigit wrote:
> On 7/30/2024 3:55 PM, Bruce Richardson wrote:
> > As meson processes our DPDK source tree it manages dependencies
> > specified by each individual driver. To enable future analysis of the
> > dependency links between components, log the dependencies of each DPDK
> > component as it gets processed. This could potentially allow other tools
> > to automatically enable or disable components based on the desired end
> > components to be built, e.g. if the user requests net/ice, ensure that
> > common/iavf is also enabled in the drivers.
> > 
> > The output file produced is in "dot" or "graphviz" format, which allows
> > producing a graphical representation of the DPDK dependency tree if so
> > desired. For example: "dot -Tpng -O build/deps.dot" to produce the
> > image file "build/deps.dot.png".
> > 
> > Signed-off-by: Bruce Richardson <bruce.richardson@intel.com>
> >
> 
> I tested it quickly, good to have this dependency list, at least it
> makes some duplicated dependencies obvious from .dot file.
> 
> But generated dependency graph is too large to be useful, does it make
> sense to have a new meson option that control this dependency generation:
> -Dgenerate_deps=apps
> -Dgenerate_deps=libs
> -Dgenerate_deps=drivers
> -Dgenerate_deps=all
> 

I had indeed noticed that. Right now I'm focused on cutting down our
dependency lists to make things more manageable - I have a script to
automate the identification of excess dependencies and I already have a
patch for cleaning up the libraries to a minimal dependency set.

I also think having separate drivers and libraries charts could be useful I
wouldn't want to add a build option for it though - it's not something that
should be necessary. Instead, I will look at other options, perhaps even
doing multiple dependency files - they don't seem to slow meson down, so
why not always do them all.

> Not sure about what should be the default option,
> as this is not always required/used, disabling this option by default
> saves unnecessary work,
> but disabling it by default may cause not noticing when it is broken,
> perhaps this can be addressed by adding this option to
> 'devtools/test-meson-builds.sh'.
> 
> btw, it generates following warning:

Oops - will look to fix in V2.

/Bruce