On Fri, 10 Dec 2010, Bill Janssen wrote:
Andi Vajda <va...@apache.org> wrote:
If I switch to Mike's recommendation then 10.6 is broken out of the box.
I don't know what developer package he's referring to. Can you please
send me the URL ?
Here's what his message said:
``It may be necessary to install the "Java for Mac OS X 10.6 Update 3
Developer Package" or "Java for Mac OS X 10.5 Update 8 Developer
Package" from <http://connect.apple.com> under the "Java" section, to
ensure the native headers are present in the JavaVM.framework. We are
aware that this has caused some inconvenience for otherwise native
projects that make use of the JNI API, and we are leaning towards just
shipping the headers in the regular customer software update package.''
That's the "developer package" he's referring to.
Yes, your patch should work on both but would it not be obsoleted by
the next time Apple moves these headers around again and setup.py is
reverted back to the /System value in consequence ?
I really want the latest up to date Mac OS X setup to build out of the
box
Sure, me too!
No, not today. Today's out of the box on 10.6 requires the setting to be
under /Developer (without your patch). Downloading another Java package !=
out of the box. By out of the box, I mean current Xcode + whatever software
update drops in on a regular basis, like the last Java update that lost the
headers.
...and it seems that the current setup.py settings are the only way
unless your patch get added ?
My patch soft-codes the location of the SDK, so that it works with both
10.5 and 10.6. Though, after hearing from Swingler, I'd revise it as
follows (I just did this in Emacs, haven't tested it):
Ok then, provide a tested patch that works and applies out of the box to
JCC's trunk, and that puts this code into a new helper file like is done for
linux and windows (thus not adding pages of code to setup.py) and I'll
integrate it.
In other words, first look for the headers where Apple says they should
be, then if they aren't there, look in the Developer SDK, but the SDK
for the current version of OS X.
Philosophically, I see little point in avoiding the use of an actual
programming language that using setup.py gives you. Otherwise, might as
well use another Makefile.
You're not adressing the issue here: obscure automatic failures vs simple
edits in setup.py to match your system.
Andi..
