lucene-pylucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andi Vajda <>
Subject Re: [VOTE] Release PyLucene 2.9.4-1 and 3.0.3-1 (take 2)
Date Fri, 10 Dec 2010 22:28:09 GMT

On Fri, 10 Dec 2010, Bill Janssen wrote:

> Andi Vajda <> 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 <> 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 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 

>> ...and it seems that the current 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 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 gives you.  Otherwise, might as
> well use another Makefile.

You're not adressing the issue here: obscure automatic failures vs simple 
edits in to match your system.


View raw message