On Apr 24, 2008, at 2:33 PM, Christopher Barker wrote:

William Kyngesburye wrote:
This rambling was probably unnecessary, but the upshot is don't expect Apple to add other image libraries to the system or X11. We're on our own.

OK. So I see it this way:

For the "MacPython" build (2.5.2, runs on OS-X 10.3.9 and above), we need:
  libpng
  libfreetype
  libjpeg
  others?

For Apple's 2.5 build that comes with leopard, we need:
  libjpeg
  (freetype and png can come from X11)

Is that right? Or should we just use our own for Apple's build too?

Consistency is nice, especially on older systems that may have an old version where the changes include new features (as opposed to bug fixes). PNG updates are mostly bug fixes these days, but include important security updates that would be nice to have (Apple may update the system PNG but not X11 PNG?).

Note: my frameworks are now for Tiger+ only. I dropped the Panther compatibility with the release of Leopard. It is possible to build the frameworks for Panther, though my current Xcode projects will only work on Leopard (you'd have to use the 10.3.9 SDK). I'm working on a non-Xcode method to easily create frameworks from the unix sources (except UnixImageIO, which needs the Xcode project).

William, what do you think of my idea of trying to get distributors to standardize on your Frameworks?

Thanks. That was generally the idea, but I'm not a very proactive person ;)

I haven't gotten any feedback yet, but I now some folks would rather not have any dependencies, even if they are easy to install. However, it really is a big 'ol pain in the *&^& to build universal versions of all these various libs. Would you consider adding static libs to your Frameworks so that we could at least tell distributor that they can just install a couple Frameworks and have all the static libs they need?

Using static libs, even if everyone uses the same binary, is basically what occurs now. All it really does is relieve the developers of compiling dependencies (though that's part of what you're talking about). But, static libs don't really belong in frameworks (and I don't like bloat).

An option would be to bundle the frameworks in the Python framework. It would then be a courtesy of the Python packaging, and the Python packagers might not want to do that.

If someone distributes a python application bundle (py2app or from Xcode), bundling the frameworks in that app's package would work, since framework bundling is standard stuff in applications.

But for a Python extension (and other libraries and CLI programs that have no bundle home), I think worrying about dependency installation may be necessary.


Creating an installer for a python extension that includes the necessary frameworks is an option. On Panther it may be tricky to have it install them only when absolutely necessary (ie not overwrite existing installed frameworks), but a Tiger/Leopard installer package can easily be made to do so.

When I say existing installed frameworks, I mean compatible, though not necessarily more recent. With a common shared framework I don't think it would be nice to blow away an older version with a newer version if the older one is compatible. The installer can make the "update" optional.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

"Those people who most want to rule people are, ipso-facto, those least suited to do it."

- A rule of the universe, from the HitchHiker's Guide to the Galaxy


_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Reply via email to