mark brethen <mbrethen@aim.com> on Saturday, May 19, 2007 at 7:05 AM -0800 wrote:
Just to update you on the status. I contacted the mp3splt author at sourceforge.net and he was able to walk me through the install. After updating the libmad port I had to use
export CFLAGS="$CFLAGS -I/opt/local/include" export LDFLAGS="$LDFLAGS -L/opt/local/lib"
before configuring libmp3splt. The latest build of mp3splt (subversion) fixes the cddb function. This doesn't work in the version that the mp3splt port installs. If someone would guide me, I could create an alternate (i.e. subversion) port install.
Ah I see. When installing software manually, it will usually need to be told where to find MacPorts libraries. That is only one reason I don't do it anyore. If a port I need doesn't exist, I create it. I don't understand the difference between libmp3splt and mp3splt. Do we need a port for each? Also, there are several ways to handle updating a macport to handle newer (but beta or alpha) code. 1) One way is to create a portname-devel package in cases where a new version introduces incompatibilities *and* actual users we currently have will want to use both. Just the mere hypothetical possibility of needing both is insufficent to create to ports, and only to be done when necessary. 2) If the alpha or beta is fairly stable, or the user base of the port is low, or the bugs solved are significant enough that is is preferred to use the beta over the release for most users, then it is justified to use betas, release candiates, and even alpha code under the right circumstances. We don't like port and variant proliferation without good reasons. So the question is, is the mp3splt2.2_rc1 solve your problem? And in your judgement does it meet the criteria of #2? If so, we could update the port to rc_1. If not, if the particular bugfix in subversion is a discrete patch or patches, those could be added to the port to make the port more usable. Mark