Any common policy against conflicting choice in Makefile
OPTIONS?
Olli Hauer
ohauer at FreeBSD.org
Sun Feb 5 17:37:49 UTC 2012
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)
> 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.
More information about the freebsd-ports
mailing list