Page MenuHomeFreeBSD

share/mk: basic support for group options
ClosedPublic

Authored by brooks on Aug 30 2023, 9:57 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Nov 4, 11:01 AM
Unknown Object (File)
Mon, Nov 4, 11:01 AM
Unknown Object (File)
Mon, Nov 4, 11:01 AM
Unknown Object (File)
Mon, Nov 4, 11:01 AM
Unknown Object (File)
Mon, Nov 4, 10:57 AM
Unknown Object (File)
Mon, Nov 4, 10:57 AM
Unknown Object (File)
Mon, Nov 4, 10:57 AM
Unknown Object (File)
Mon, Nov 4, 10:44 AM
Subscribers

Details

Summary

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
FOO_OPTIONS).

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

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
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 BROKEN_SINGLE_OPTIONS
  • Add copy to kern.opts.mk
  • Unset __SINGLE_OPTIONS

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.
share/mk/bsd.mkopt.mk
34–37

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.

share/mk/bsd.mkopt.mk
34–37

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
# by __FOO_OPTIONS.

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.
share/mk/bsd.mkopt.mk
34–37

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.