Re: [PATCH v1 1/1] usertools: add DPDK build directory setup script

["Burakov, Anatoly" <anatoly.burakov@intel.com>]

On 9/5/2024 9:29 AM, David Marchand wrote:
> On Wed, Sep 4, 2024 at 5:17 PM Anatoly Burakov
> <anatoly.burakov@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.burakov@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