2010/10/4 Brandon S Allbery KF8NH <[email protected]> > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 10/3/10 21:21 , Nikos Chantziaras wrote: > > Thanks, Ryan. I suppose I will need to find someone who has a 10.5 > > installation to do a sanity check for me before I release any binaries > > tagged with "OS X 10.5 and newer". > > Distributing binaries built via MacPorts tends to be a bad idea: not only > do you need to make sure to distribute the files from any dependencies as > well as your binary, but the result will likely interfere with an installed > MacPorts or Fink on the installer's machine. > > No, that's not true. An application that is to be distribibuted and which is a true Mac bundle is always "self-contained". It should only be linked outside the bundle in case of system libraries. In the case of the hugin bundle and the avidemux bundle, the bundles contains lots and lots of libraries and frameworks where the linker paths are "rerouted" to paths inside the bundle. This is exactly where the "install_name_tool" on OSX is for and what XCode itself uses extensively.
This mechanism is exactly there to prevent the interference with an installed MacPorts or Fink or whatever installation. If you check graphical applications for example you will see that they all contain jpeg, tiff, png libraries and in case of QT applications the QT frameworks as well. This causes a lot of redundancy but it also enables you to build a truly portable application. Harry
_______________________________________________ macports-users mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
