Interesting. Real examples might be easier to understand than generic opt1 and opt2.

In D3409#69643, @wblock wrote:

Interesting. Real examples might be easier to understand than generic opt1 and opt2.

I've been trying to write examples, but they're all phony, and don't look any better than the generic opt1/opt2, and they don't add any information from what is already there.

Hi Mat,
Looks pretty good, for what it's worth I have 2 comments:

1. I see the OPT_IMPLIES and OPT_PREVENTS as macros which assist in the selection of which options are enabled, similar to the OPTIONS_SINGLE and OPTIONS_RADIO grouping, rather than option helpers which add some Makefile logic once an option has been enabled. Hopefully one day dialog4ports will be updated to represent the conflict/dependency logic in the user interface for selection options, rather than waiting until after the user has attempted to make a selection. With that in mind, I feel like the documentation for these macros belongs either in the same section as the OPTION_SINGLE and OPTIONS_RADIO grouping syntax (section 5.12.1.2), or in it's own section 4 within the same section 3 (section 5.12.1.4), rather than with the option helpers (section 5.12.3).
2. The example you have provided for OPT_IMPLIES uses the word "enable" in a different sense to the way this macro is intended. People may get confused and think this option is somehow related to the OPT_CONFIGURE_ENABLE helper for specifying compile time --enable-opt syntax, rather than what it actually does which is simply enable the option and any other specified actions that come with it. I'm not sure the example needs to go so far as to explain that any normal behaviour that comes with an option would also occur, I think the text could simply state this. The example could be limited to demonstrating that even if you don't specifically enable an option, it will be enabled if you enable another option which has registered it as a dependency with OPT_IMPLIES.

Cheers,
Ben