On 9/5/2024 9:29 AM, David Marchand wrote:
On Wed, Sep 4, 2024 at 5:17 PM Anatoly Burakov
<anatoly.bura...@intel.com> wrote:
Currently, the only way to set up a build directory for DPDK development
is through running Meson directly. This has a number of drawbacks.
For one, the default configuration is very "fat", meaning everything gets
enabled and built (aside from examples, which have to be enabled
manually), so while Meson is very good at minimizing work needed to rebuild
DPDK, for any change that affects a lot of components (such as editing an
EAL header), there's a lot of rebuilding to do.
It is of course possible to reduce the number of components built through
meson options, but this mechanism isn't perfect, as the user needs to
remember exact spelling of all the options and components, and currently
it doesn't handle inter-component dependencies very well (e.g. if net/ice
is enabled, common/iavf is not automatically enabled, so net/ice can't be
built unless user also doesn't forget to specify common/iavf).
There should be an explicit error explaining why the driver is not enabled.
Is it not the case?
It is there alright, however
1) the error message is not perfect because e.g. in case of net/ice it
asks to enable "common_iavf" and doesn't say whether it's a driver or
something else, which can be confusing (and it was for me!)
2) I would still prefer this happening automatically (requires much more
effort to fix it in the build system itself and arguably isn't worth
it), and
3) preferably without typing much while still allowing me to be flexible
Enter this script. It relies on Meson's introspection capabilities as well
as the dependency graphs generated by our build system to display all
available components, and handle any dependencies for them automatically,
while also not forcing user to remember any command-line options and lists
of drivers, and instead relying on interactive TUI to display list of
available options. It can also produce builds that are as minimal as
possible (including cutting down libraries being built) by utilizing the
fact that our dependency graphs report which dependency is mandatory and
which one is optional.
Because it is not meant to replace native Meson build configuration but
is rather targeted at users who are not intimately familiar wtih DPDK's
build system, it is run in interactive mode by default. However, it is
also possible to run it without interaction, in which case it will pass
all its parameters to Meson directly, with added benefit of dependency
tracking and producing minimal builds if desired.
Signed-off-by: Anatoly Burakov <anatoly.bura...@intel.com>
There is no documentation.
I will add some in later revisions. This is just me planting the flag
before the v1 deadline :)
And it is a devtools script and not a usertools, iow, no point in
installing this along a built dpdk.
Agreed, I will move it to devtools.
I don't see a lot of value in such script.
In my opinion, people who really want to tune their dpdk build should
enter the details carefully and understand the implications.
But other than that, I have no strong objection.
I understand your perspective, but I respectfully disagree about
"entering details carefully and understanding the implications" for
basic things like enabling example applications or drivers. This may
apply for more advanced meson options like enabling IOVA as PA or
setting mbuf headroom or whatever, but these aren't provided in this
script - for those options one indeed would want to run meson manually
or at least enter additional meson arguments (implying the person has
already looked at the documentation, found the option, and more-or-less
understands what will happen when they change its value).
However, for your "standard" options such as which apps to enable, I
don't think it's a stretch to suggest it's pretty obvious what will
happen when this or that option is enabled or disabled, the difference
would be simply in the fact that one doesn't have to remember exact
syntax or spelling (e.g. is it "test-pmd"? "testpmd"? "dpdk-testpmd"?)
to work with basic options. The dependency tracking will also protect
the user from obvious mistakes such as not building mempool library or
whatever, so there are arguably no far reaching "implications" that have
to be considered here.
--
Thanks,
Anatoly
