Any common policy against conflicting choice in Makefile OPTIONS?

[Chris Rees]

On 5 February 2012 17:21, Olli Hauer <ohauer at freebsd.org> wrote:
> On 2012-02-05 17:19, RyōTa SimaMoto wrote:
>> Hi, I'm a port maintainer for multimedia/qmmp, and some ports.
>> Before upgrading QMMP port, may I ask what is the common policy how to
>> offer Makefile OPTIONS containing a certain contradictory pair?
>>
>> Actually the latest version of QMMP supports several versions of ffmpeg,
>> including 0.7.11, 0.9, 0.9.1, and 2012.01.22 that I tested to verify, so it
>> allows user to choose one of multimedia/ffmpeg or multimedia/ffmpeg-devel.
>> As you know you should not select both of them, otherwise they may conflict
>> with each other.  I plan to provide an entry for each of them.
>>   | ....
>>   | [*] FFMPEG        Support to playback by FFMPEG
>>   | [ ] FFMPEG_DEVEL  Support to playback by FFMPEG-devel
>>   | ....
>> Then how should the Makefile proceed after the user's choice?
>>
>> When the user did not install any of them yet, it's easy: The installation
>> would obey the user's order except when occationally both of them are
>> enabled that results to fail with an alert message.  On the other hand, if
>> one of them are already installed, Makefile would know which one is
>> installed using 'exists(${LOCALBASE}/include/libavcodec/vda.h)' command.
>> So, in fact, there is no question that which version the user want to use.
>>
>> The smartest way would be that provides a single entry which corresponds
>> to the existing version and hides the other entry that should not be
>> choosen.  Unfortunately, the value LOCALBASE is not defined until
>> <bsd.port.options.mk> macro is loaded, that means we don't have any proper
>> steps to determine what version is already installed when the Makefile
>> construct the OPTIONS set.  So we have no other way than to let the option
>> dialog always show both entries including quite wrong option.
>>
>> Then if the user selects the other one that might conflict with the
>> installed version, there are six possible courses I assume.
>>  0x000.  Quit the session with alert message instructing user to retry
>>          'make config' to choose the already installed one that Makefile
>>          knows.
>>  0x001.  Dare to go through and expect that the depending port deals with
>>          the conflicting issue.
>>  0x002.  Use the installed version and omit the choice implicitly.
>>  0x004.  Warn with short pause, then use the installed version and omit
>>          the choice.
>>  0x010.  Store options into /var/db/ports/* as are that the user selects.
>>  0x020.  Store options into /var/db/ports/* with correction as actually
>>          working.  (If option variables are allowed to be changed at
>>          testing stage.)
>>
>> Is there any recommended policy?  If so, what way or a set of ways should I
>> choose?
>>
>>
>
> The following patch will do what you want, just polish the IGNORE messages.
> Hopefully the include files do not change with the next versions.
>
>
>
>
> --- Makefile.orig       2012-02-05 17:53:58.000000000 +0100
> +++ Makefile    2012-02-05 18:16:00.000000000 +0100
> @@ -35,6 +35,7 @@
>                FLAC    "Support to playback FLAC files" on \
>                MUSEPACK        "Support to playback MPC files" on \
>                FFMPEG  "Support to playback FFMPEG files" on \
> +               FFMPEG_DEVEL    "Support to playback FFMPEG-devel files" on \

Hm, breaks itself by default ;)

I still think depending on ffmpeg binary and defaulting to
multimedia/ffmpeg and just having the one OPTION is the simplest
solution.

Chris