Any common policy against conflicting choice in Makefile OPTIONS?

Da Rock freebsd-ports at
Sun Feb 5 23:19:05 UTC 2012

On 02/06/12 03:41, Chris Rees wrote:
> On 5 February 2012 17:37, Olli Hauer<ohauer at>  wrote:
>> On 2012-02-05 18:23, Chris Rees wrote:
>>> On 5 February 2012 17:21, Olli Hauer<ohauer at>  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
>>>>> <>  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.
True +1.

Usually it is this that breaks most similar ports (xine, mplayer, etc). 
Can't install devel without breaking, and to fix you have to install the 
non devel version.

JIC: this is not an official complaint, or a stolen thread. Just an 
observation for the OP to consider when setting their own port.

More information about the freebsd-ports mailing list