-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do something smarter with options #4574
Comments
One thing I wanted to do is to split per subproject the output of When we'll add some per-subproject built-in options, that also would require a refactoring of that output. |
It might also be nice to group arguments based on what they do (group the |
Are we speaking about the output of |
ah, my bad, configure |
In #4626 I tried to do |
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.) |
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. |
What about having some sort of |
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 (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.] |
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. |
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.
The text was updated successfully, but these errors were encountered: