parumi at iua.upf.edu
Fri Feb 23 09:47:08 PST 2007
En/na Kevin Ballard ha escrit:
> In general, building something with MacPorts and shipping it as part
> of an application is a risky business. I strongly recommend building
> the library yourself instead of relying on MacPorts to do it.
> One example of this is the app HyperEdit. When the developer added the
> feature where HyperEdit can validate your HTML documents, he used the
> openjade port from MacPorts. Unfortunately this feature didn't work
> for anybody that didn't already have all of openjade's dependency's
> installed via MacPorts. I sent the author an email and he very quickly
> put out a new version that used the correct library linker paths to
> fix this problem.
well i can add a success story on bundling and shipping macport libs.
in our project, clam (http://clam.iua.upf.edu) we ship 3 audio-related
applications with many dependencies (qt3 and qt4 among them).
we created this python script very simple to use:
you prepare the bundle and call:
addDependentLibsToBundle( "Annotator.app" )
it will recursively find all dependent (including indirect dependencies)
libraries, copy them the bundle Contents/Frameworks and change its
absolute path to the correct relative path.
hope it might be useful to others.
about binaries, we tried but found it too hard. we just have two boxes
(ppc+intel) and distribute two different packages -powerpc.dmg and
-intel.dmg. this way you have the bonus that the user downloads half the
size of a single universal.
> On Feb 23, 2007, at 12:16 PM, Julian Yu-Chung Chen wrote:
>> Say my application will build a library which statically link to
>> several libraries in MacPorts , so what I need is the universally
>> built library binary. Then my app can just bundle required UB libs.
>> What I can do now is using lipo to stitch intel and ppc binaries
> Kevin Ballard
> eridius at macports.org <mailto:eridius at macports.org>
> macports-users mailing list
> macports-users at lists.macosforge.org
More information about the macports-users