Re: [PATCH v3 5/9] eal: define the EAL parameters in argparse format

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

On Mon, Jul 21, 2025 at 10:05:23AM +0100, Bruce Richardson wrote:
> On Mon, Jul 21, 2025 at 10:41:33AM +0200, David Marchand wrote:
> > On Fri, Jul 18, 2025 at 4:34 PM Bruce Richardson
> > <bruce.richardson@intel.com> wrote:
> > > +struct eal_init_args {
> > > +       /* define a struct member for each EAL option, member name is the same as option name.
> > > +        * Parameters that take an argument e.g. -l, are char *,
> > > +        * parameters that take no options e.g. --no-huge, are bool.
> > > +        * parameters that can be given multiple times e.g. -a, are arg_lists,
> > > +        * parameters that are optional e.g. --huge-unlink,
> > > +        *   are char * but are set to (void *)1 if the parameter is not given.
> > > +        * NOTE: List is to be kept alphabetically by option name
> > > +        */
> > 
> > We will have to be careful to keep this struct below, in sync with the
> > options list.
> > Could we construct (at build time) this structure via the options list?
> > 
> > The rules above would be enforced at the same time.
> > 
> > (macros + #ifdef for Linux/FreeBSD may be an issue for MSVC though...)
> > 
> 
> I wonder how much an issue keeping them in sync would actually be? When
> adding a new option to the options list, it takes a reference to the struct
> field, meaning that we can't forget to add an entry here when adding the
> option. If we add here but forget to add to the options list, then obvious
> the option just doesn't get parsed so testing quickly would show up the
> issue.
> 
> I suppose the main concern would be around renaming or deleting options -
> though in the latter case having an extra stray element in the struct isn't
> a big deal.
> 
> I might have a shot at auto-generating the struct, but I'm not convinced
> the complexity will be worth the benefit.
> 
Auto-generating the struct seems to work fairly ok. Will include in next
revision.

/Bruce