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