[MPlayer-cygwin] get_path cygwin

[Joey Parrish]

On Sun, Nov 28, 2004 at 08:24:08PM +0100, Diego Biurrun wrote:
> On Sat, Nov 27, 2004 at 07:04:29PM -0600, Joey Parrish wrote:
> > On Thu, Nov 25, 2004 at 11:57:44PM -0500, compn wrote:
> > > trying to build my own cygwin mplayer, and cant figure the path
> > > part, mplayer keeps trying to load codecs.conf from a diff dir than
> > > i want it to.
> > > 
> > > e.g. my mplayer returns
> > > get_path('input.conf') -> '/cygdrive/c/Documents and Settings/resu/.mplayer/input.conf'
> > > Can't open input config file /cygdrive/c/Documents and Settings/resu/.mplayer/input.conf: 
> > > joey's mplayer returns
> > > Parsing input config file C:\programs\mplayer\input.ini
> > > Input config file C:\programs\mplayer\input.ini parsed: 44 binds
> > > 
> > > can joey's get_path be sent into main?
> > > "hijack get_path in favor of my own version"
> > > http://mirror-unt.nicewarrior.org/cygmp/20040928/patches-20040928/40.winstuff.patch
> > 
> > Absolutely not.  If you are custom compiling it to run in a cygwin
> > environment, just specify the data path with configure.  My patch to
> > look in the executable's directory ONLY makes sense for a packaging
> > environment where there is no cygwin environment and the installation
> > location is unknown at compile time.
> 
> Apparently this would be a desirable feature for Mac OS X as well to build
> an app bundle (or whatever it's called), see the thread on dev-eng.

Well, OSX has to do it a different way than Windows anyway.  Package
maintainers have always had to keep a patch set for packaging because
packages are always different.  I fail to see why so many packagers want
every tiny tweak to the install environment committed to CVS.  It makes
no sense.  I have a huge patch set to my packages.  Anything that seems
like it belongs in CVS, I try to commit.  But a lot of things don't
belong, and this, IMHO, is one of them.

--Joey

-- 
"Living in the complex world of the future is somewhat
like having bees live in your head.  But, there they are."