Do something smarter with options

[jpakkane]

We have a lot of options, which makes the option list already quite difficult to decipher. We are probably going to get more, see for example #2567. This means we should have some better way of managing them.

A possible option is to mark rarer options as "advanced" and hide them by default. They would only be shown if doing meson configure --advanced.

Other approaches to providing for this are gladly accepted. This is just something I come up with after 10 minutes of thinking.

[xclaesse]

One thing I wanted to do is to split per subproject the output of meson configure, and hide subproject options if they yield and overriden by the parent. Also wrap description/choices columns to fit on the terminal width but that could be complicated.

When we'll add some per-subproject built-in options, that also would require a refactoring of that output.

[dcbaker]

It might also be nice to group arguments based on what they do (group the --prefix and --libdir separately from --wrap-mode or --debug. IIRC argparse can do that.

[xclaesse]

Are we speaking about the output of meson configure or meson setup --help here?

[dcbaker]

ah, my bad, configure

[Ericson2314]

In #4626 I tried to do compiler_options.{build,host,target}. But this is proving to be a nastier refactor than I hoped. I then tried doing user_options[subproject][option] as a warm-up refactor, but that also proved annoying. I'd love to collaborate with someone on option fixing so I can smoothly get in the rest of my cross compilation overhauling.

[Ericson2314]

What about sqlite? If we do one big table we can have partial indices for everything that's a separate dict today, we could probably do all our queries faster (no more iterating through dicts trying each one nonsense.)

[jpakkane]

This has nothing to do with how the options are stored, but instead the user experience they give. Showing 100 options to the user is just plain bad usability. Having 100 options of which 80+ are hidden by default and users don't need to touch in most cases is not awesome but it is tolerable. Having 1000 options is bad no matter what so reasonably the option set size is at most a few hundred. With these data set sizes iterating over dicts is fast enough even on a Raspberry Pi.

[strega-nil]

What about having some sort of cpp_options={rtti=off, std=c++17, ...}? Doing it with objects instead of with explicit option names for every language seems reasonable.

[Ericson2314]

Sure. Performance isn't so interesting to me (I shouldn't have emphasized lookup-time, sorry), rather the mismatch between a flat space of names, and the hierarchical records into which the options are parsed, is. Exposing those directly as @ubsan says, or (basically equivalently) having hierarchical names like compiler_options:host:cpp:rtti, would both make the namespace more navigable as a user, and simplify the implementation.

(The sqlite suggestion I mentioned before was the only way I could think of to cleanly support the flat namespace and structured internals, but I rather just get rid of flatness.]

[anarazel]

Would it perhaps be possible to explicitly "opt in" or "opt out" of options that are/aren't relevant for a project? E.g. lots of projects won't work with unity builds, a flat project layout, don't use C++, don't use all of the directories etc. So meson configure displaying them all isn't helpful.