Packages ignoring applications_dir

Bryan Blackburn blb at
Thu Sep 8 22:31:08 PDT 2011

On Thu, Sep 08, 2011 at 11:35:38PM -0500, Ryan Schmidt said:
> On Sep 8, 2011, at 21:56, Scott Webster wrote:
> > On Thu, Sep 8, 2011 at 7:06 PM, Bryan Blackburn wrote:
> >> On Thu, Sep 08, 2011 at 06:52:22PM -0700, Scott Webster said:
> >>> It forces a build from source if you use a non-standard prefix?  Wouldn't it
> >>> be straightforward to just replicate the same files into an alternate
> >>> location?  The situation here seems slightly more complex since we're
> >>> outside the $prefix/ tree...
> >> 
> >> Yup, if your prefix is not /opt/local, port always builds from source.
> >> Libraries and executables both have hardcoded paths in them (you can use
> >> 'otool -L /some/lib/or/executable' to see) so building to one location then
> >> moving will definitely break things.
> >> 
> >> There are also some ports with things like ${prefix}/etc and other paths
> >> compiled into binaries, config files with paths, and so on.  All of that
> >> means relocating would be a mess at best...
> >> 
> > 
> > Thanks for the explanation!  I guess now to complete my education I
> > should go look up how Mac OS X deals with moving application bundles
> > around...
> Application bundles are painstakingly crafted by their developers so that relocation is possible. They are a completely different animal from the kind of command-line software most MacPorts ports provide.

It's possible the app bundles in ports could be relocated, but I'm
guessing that's a lot more code in MacPorts than simply forcing a source
build when applications_dir is not the default.  Long-term it would make
sense, but like most things MacPorts, someone needs to code it first; and
the code to skip the archive and build from source is already there...


More information about the macports-users mailing list