Page MenuHomeFreeBSD

share/mk: basic support for group options

Authored by brooks on Aug 30 2023, 9:57 PM.
Referenced Files
F78310986: D41659.diff
Fri, Mar 1, 7:50 PM
Unknown Object (File)
Jan 11 2024, 12:52 PM
Unknown Object (File)
Jan 7 2024, 4:10 PM
Unknown Object (File)
Jan 7 2024, 3:55 PM
Unknown Object (File)
Dec 23 2023, 1:39 AM
Unknown Object (File)
Dec 13 2023, 10:26 PM
Unknown Object (File)
Nov 25 2023, 2:03 AM
Unknown Object (File)
Nov 23 2023, 10:39 AM



Support group options where 1 of n values will be selected (or a default
value will be used). After processing an OPT_FOO will be set to one
value from FOO_OPTIONS for each FOO in SINGLE_OPTIONS. If the user
sets FOO that value will be used, otherwise
FOO_DEFAULT will be used
(if FOO_DEFAULT is not explicitly defined it will be set to the first
value in

This is somewhat inspired by OPTIONS_SINGLE from ports, but the
structure is quite different with a per-option variable a la MK_FOO.

Diff Detail

rG FreeBSD src repository
Lint Passed
No Test Coverage
Build Status
Buildable 53395
Build 50286: arc lint + arc unit

Event Timeline

Ports also has RADIO, GROUP, and MULTI for different set types, but this is the one I want now.

We might eventually want to interact with __DEFAULT_DEPENDENT_OPTIONS options, but I don't want to try to work that out without a use case or two.

@jrtc27 rightly points out I should add makeman (and thus showconfig) support. I'll look into that in followup commits.

  • Add copy to

I like this... And the make foo isn't too bad...

This revision is now accepted and ready to land.Aug 31 2023, 10:22 PM

I did realize as I was working on makeman support that we should also implement what ports calls MULTI options to tame the LLVM backend support, but I'd like to land this stack first as I need to get back to the work that motivated it.

were -> where in the commit message

emaste added inline comments.

I find the description a little confusing. If an example can reasonably be included I think it might make it more clear.

I've been debating if __FOO_DEFAULT and __FOO_OPTIONS should have the __ prefix. I think it's arguable that they are part of the public interface, but I'm not sure.


I'm somewhat tempted to drop the FOO_DEFAULT:=${FOO_OPTIONS:[1]} thing and just make it an error to not set __FOO_DEFAULT. If it did that would the text be clearer as:

# For each option in __SINGLE_OPTIONS, OPT_FOO is set to FOO if
# defined and __FOO_DEFAULT if not.  Valid values for FOO are specified

It's hard to work an example here since use to OPT_FOO is elsewhere.

This revision now requires review to proceed.Aug 31 2023, 11:54 PM
emaste added inline comments.

I think requiring FOO_DEFAULT is fine

This revision is now accepted and ready to land.Sep 1 2023, 12:13 AM

Require explicit __FOO_DEFAULT

This revision now requires review to proceed.Sep 1 2023, 12:42 AM

Require explicit __FOO_DEFAULT

I'm agnostic on this being required. I'm good with it though

This revision is now accepted and ready to land.Sep 1 2023, 12:47 AM
This revision was automatically updated to reflect the committed changes.