Jacob Meuser wrote:
On Mon, Jul 04, 2005 at 02:41:35AM -0500, Edd Barrett wrote:
On 7/4/2005, "Jacob Meuser" <[EMAIL PROTECTED]> wrote:
On Mon, Jul 04, 2005 at 11:32:47AM +0100, Edd Barrett wrote:
Hello,
Here is a port for eq-xmms. A plugin that will allow equalization of any
file format, not just mp3.
I've had great results with this piece of software EQ'ing my vorbis
files, but as for the build, I'm not sure and would like your opinions.
The configure script is linux-centric. It reads /proc/cpuinfo to see
what arch your machine is and if it has SSE and MMX and all the other
buzzwords. If this fails (obviously in obsd it does) then it assumes x86
. I tried building on my sparc and it failed. For now all I have done is
patched the configure script to not make that assumption. Its a dirty
hack I know.
I did try playing around with cpudetect.c and I tried things like
getting arch from param.h, but they ended up being even dirtier ,as it
has already made the x86 assumption.
What do you guys think?
I think you are abusing WANTLIB and forgetting about LIB_DEPENDS.
also, I think a better name would be xmms-equ. note that the other
xmms plug-ins are named xmms-<whatever>.
--
<[EMAIL PROTECTED]>
--
This email has been verified as Virus free
Virus Protection and more available at http://www.plus.net
Hi,
Thanks for yor comments, I will look into that.
Did you have any comments on the build itself? Did you take a look at
cpudetect.c and configure? As I say, I'm unsure the best way to patch
this to build.
generally speaking, only MMX should be built into i386 binaries.
don't forget, that the ports system is used to make packages, and
packages are the preferred method of installing software.
also remember that packages may be built on a "fast" machine, but
used on a "slow" machine.
so, unless you can test building the packages on a machine where SSE/
SSE2 is supported, and the packages work on, say, a 486, it's best to
disable extended cpu capabilities.
the other option is to make an "optimized" flavor, such as with
multimedia/mjpegtools.
IMO, disable optimizations until the rest of the port is OK. then
more people can test if the extended code works. according to the
$HOMEPAGE, it looks like they've had some problems with this stuff
anyway.
Hi again,
Im not sure about your WANTLIB concern.
Here is the wantlib line from xmms-flac, which has been checked in and
therefore approved.
WANTLIB= X11 Xext Xi gdk glib gmodule gtk iconv intl m
here are my WANTLIB lines (from the port I have previously submitted)
WANTLIB= gmodule Xi X11 iconv intl m glib Xext gtk \
xmms pthread gthread gdk
Similar would you not agree? I have decided to remove xmms in favour of
LIB_DEPEND as it will compile directly against that. make newlib-depends
check is happy with this. What is your concern (unless you just meant
libxmms)?
I have changed the naming convention on my local copy as requested and
removed the hard coded version number.
Reguarding CPU optimizations, the patch makes no CPU assumptions. The
safest option. However I dodn't think people would approve of patching a
configure script.
And yes.. they have had trouble, but overall it does work well.
Thanks for your time
Edd
