[Pythonmac-SIG] bundlebuilder bug?

[Bob Ippolito]

On Jan 23, 2004, at 3:49 PM, Russell E. Owen wrote:

> I just submitted this to sourceforge, but thought I'd see if anybody 
> had
> any suggested workarounds. I'm also unclear if I should be reporting a
> 2nd bug as well.

Next time it'd be cool to get a URL for it in the bug tracker, only 
Jack gets email notifications about this stuff, and it's sort of a pain 
to dig around in sourceforge's bug tracker.

> The bundlebuilder command-line argument --lib is supposed to be able to
> include frameworks in the resulting Mac application package.
> Unfortunately, the aliases in the resulting framework copy are all
> broken.
>
> For an example of this, use --lib to include Tcl.framework and then 
> look
> through the framework in the resulting application package. Frameworks
> normally have quite a few handy aliases (such as .../Versions/Current)
> and all the aliases I tried were broken.
>
> I'm not entirely sure if this actually breaks anything. The one app 
> I've
> managed to build with standalone=True and use of --lib to include the 
> Tk
> and Tcl frameworks runs fine on my Mac (which has Python, Tcl and Tk
> frameworks installed) but fails with "True undefined" on another Mac
> running Jaguar that I happened to have handy.

These symbolic links are never used by the runtime as far as I know.  I 
think they're mostly for humans and compilers -- unless maybe something 
goes wrong during the link (dyld fallback environment variables or 
something).

> This 2nd problem may be a separate bug or user error on my part. I'm 
> not
> yet sure.

Not sure, there really isn't enough information to go on.  If you are 
running 10.3 on your machine, all bets are off.. --standalone will not 
produce a 10.2 compatible app bundle, --semi-standalone *probably* 
won't either because you have to set up a compile time environment 
explicitly make things 10.2 deployable (and have the SDKs installed), 
Python.framework itself certainly is not (compiled by Apple), and none 
of the modules in PackageManager (both Jack's and mine) are necessarily 
10.2 deployable and are likely to have dyld issues anyway because the 
Python.framework paths are different.

Short answer: if you want your Python apps to run on Jaguar, you need 
to make them on Jaguar.

> P.S. I finally got my extra files properly installed by adding to the
> bundlebuilder script such that it:
> - unpacks Modules.zip
> - copies the two packages in question (overwriting the incomplete
> versions that were already installed; I plan to try excluding them and
> leaving Modules.zip alone).
> The results work on my machine but break on a Jaguar machine is noted
> above with True undefined -- as if it's running the python on that
> machine instead of the framework python that's in the application
> package.

If you exclude a module/package (so it won't go in Modules.zip), and 
then include it (either as a resource or a module, it doesn't really 
matter) then this problem should be solved.  No need to modify the code 
for bundlebuilder.

That said, I have personally modified a copy of bundlebuilder that 
fixes the aforementioned symlink bug, and adds a slew of additional 
features with regard to embedding modules and frameworks (it actually 
scans your extensions and automatically locates any dylibs/frameworks 
they depend on.. rewrites all of their headers and chunks them into the 
app bundle).  I'll clean this up and release it someday if people bug 
me about it on a semi-regular basis :)

-bob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2357 bytes
Desc: not available
Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20040123/80995d2e/smime.bin