Any common policy against conflicting choice in Makefile OPTIONS?

Chris Rees crees at freebsd.org
Sun Feb 5 17:42:00 UTC 2012


On 5 February 2012 17:37, Olli Hauer <ohauer at freebsd.org> wrote:
> On 2012-02-05 18:23, Chris Rees wrote:
>> 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 ;)
>
> where?
> (Maybe I had not enough sleep tomight)

Here (both are on by default):

+.if defined(WITH_FFMPEG) && defined (WITH_FFMPEG_DEVEL)
+IGNORE=        coose only one FFMPEG option
+.endif

>
>> I still think depending on ffmpeg binary and defaulting to
>> multimedia/ffmpeg and just having the one OPTION is the simplest
>> solution.
>
> Sure, but the OP maybe wants to give the ability to choose which ffmpeg version in case the ffmpeg port is not already installed.

I'm just pointing out that it's not easy, and probably not a good idea :)

If the user cares that much about which ffmpeg version is installed
s/he would have installed it already.

Chris


More information about the freebsd-ports mailing list