Date: Thu, 13 Sep 2007 12:28:01 -0500 From: "Jeremy Messenger" <mezz7@cox.net> To: "Danny Pansters" <danny@ricin.com> Cc: freebsd-multimedia@freebsd.org Subject: Re: [patch] multimedia/kmplayer update to 0.9.4a Message-ID: <op.tylr4zyb9aq2h7@mezz.mezzweb.com> In-Reply-To: <200709060114.15244.danny@ricin.com> References: <1188929661.62988@caprica.slowicza.org> <200709042112.07555.fbsd.multimedia@rachie.is-a-geek.net> <200709060114.15244.danny@ricin.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 05 Sep 2007 18:14:14 -0500, Danny Pansters <danny@ricin.com> wro=
te:
> On Tuesday 04 September 2007 21:12:06 Mel wrote:
>> Hi,
>>
>> sorry to intrude, but...
>>
>> On Tuesday 04 September 2007 20:14:21 Pawel Pekala wrote:
>> > -###
>> > -## Lib Detection
>> > -###
>> > -# gstreamer
>> > -.if exists(${X11BASE}/lib/libgstplay-0.8.so)
>> > -WITH_GSTREAMER=3Dyes
>> > -.endif
>> > -# xine
>> > -.if exists(${X11BASE}/lib/libxine.so)
>> > -WITH_XINE=3Dyes
>> > -.endif
>>
>> Is it really necessary to do this automagical detection without
>> user-override? It happens frequently that I try some library for a fe=
w
>> days/weeks, in between ports get upgraded and uninstalling that libra=
ry
>> suddenly reports 10 more dependencies.
>> Would be nice if these constructs were at least created as:
>> .if exists(${X11BASE}/lib/libgstplay-0.8.so) && =
>> !defined(WITHOUT_GSTREAMER)
>
> Looks to me that this patch is wrong, but mostly so is the original po=
rt.
>
> If you use OPTIONS, you shouldn't use constructs like exists() at all,=
=
> but
> rather only have the proper LIB_DEPENDS (or USE_*) added if the option=
=
> is set
> to on. Even if, for example, xinelib is present, if the user keeps the=
=
> option
> unset it should *not* build or install kxineplayer. Or remove the =
> OPTIONS if
> it's not possible to use them as intended. If you have OPTIONS they =
> should
> override anything else (POLA).
>
> Attached is a reworked diff for the port update plus proper OPTIONS =
> handling
> and removing non essential comments. Special flags for gcc42 don't see=
m =
> to be
> needed (anymore?). Besides, disabling the standard -O2 flag should onl=
y =
> be
> done as the very last resort IMHO because if that goes wrong there mus=
t =
> be
> some underlying problem. I don't see -pedantic when building with eith=
er
> g++34 or g++42. If needed, I don't mind removing that.
>
> Tested on -STABLE with both gcc34 and gcc42, ack'd that kgstplayer,
> kxineplayer are installed when asked for, and that runtime switching =
> between
> backends is possible (I apparently don't have the proper formats enabl=
ed
> withy xine, gst to actually see and hear anything when testing but tha=
t's
> most likely a local thing). Not tested on tinderbox (but I did test
> deinstall/plist on my -STABLE box).
>
> I use kmplayer a lot as my principal KDE video player, and so if =
> multimedia@
> would rather not maintain it or doesn't have the manpower, I'm willing=
=
> to add
> kmplayer maintainership to my workload.
I have no problem with pass on the maintainership from multimedia@ to yo=
u, =
since we don't take of it very well as ahze and I don't use KDE. Can you=
=
submit a new PR with latest patch (include change MAINTAINER)? I will =
taking care of that new PR. Thanks!
Cheers,
Mezz
> CC'd original submitter and the person who commented on it (to whose =
> mail this
> is a reply).
>
> Cheers,
>
> Dan
-- =
mezz7@cox.net - mezz@FreeBSD.org
FreeBSD GNOME Team - FreeBSD Multimedia Hat (ports, not src)
http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org
http://wiki.freebsd.org/multimedia - multimedia@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.tylr4zyb9aq2h7>