This is not a final patch, it is ideas of what could be.
Details
Diff Detail
- Lint
No Lint Coverage - Unit
No Test Coverage - Build Status
Buildable 12332 Build 12620: arc lint + arc unit
Event Timeline
Mk/bsd.port.mk | ||
---|---|---|
1107 | OPTIONS_OFF here conflicts with the OPTIONS helper usage of "_OFF". _FORCE and _EXCLUDE, or _ENABLE/_DISABLE might be clearer. |
Mk/bsd.port.mk | ||
---|---|---|
1107 | Mmmm, I think whatever we do, we'll use keywords that have already been used before :-) I may prefer _FORCE and _EXCLUDE though, because it is what they do. |
Mk/bsd.port.mk | ||
---|---|---|
1107 | Definitely agree on the used-before thing. It's just that _OFF suggests that those options are enabled when this is not the current flavour. |
This is strange, I think it would be a good idea to differentiate them from options helpers by prefixing them with FLAVOR_ or somethinng like that, what do you think?
Another side note is we should probably add them by small chunks rather than all in one :)
I am not against adding a FLAVOR_ prefix, but I think it will make very long variable names, say, FLAVOR_python3_OPTIONS_EXCLUDE= BAR. I think, as options are all UPPERCASE, we simply need to say that flavors are all lowercase, and thus, they cannot conflict.
But I do see there is logic to restrict flavors to lowercase so it is probably fine to keep how you have it.
I think it is better to have different namespaces for flavors and OPTIONS, so that they cannot possibly be confused with one another.
You agree with bapt that we should FLAVOR_<flavor>_BROKEN rather than <flavor>_BROKEN then? You didn't make that change.
No, I did not, I said that <flavor>'s namespace was lowercase, and <OPTIONS> were uppercase, so they could not be mixed up.