On Tue, 23 Mar 2010, Bill Janssen wrote:
Bill Janssen <jans...@parc.com> wrote:
Andi Vajda <va...@apache.org> wrote:
- the --find-jvm-dll trick is in jcc/windows.py and is not a JCC build
option but a JCC run option. In other words, if you want the feature
for your extension, when it starts, invoke jcc with, among many other
things, --find-jvm-dll when you build your extension. This feature only
works with shared mode, currently.
Off the top of my head, I don't see this. --find-jvm-dll with shared
mode is a JCC thing, not a per-extension thing. You don't want
different extensions trying to use different JVMs -- they're all trying
to use the same JCC DLL. That's why I made it a JCC option, which could
be enabled/disabled via the config.py file. (That is, you could build
it shared with or without auto-find, but if you decided you wanted it
the other way, you could simply edit config.py to change it.)
The way extensions are distributed on Windows makes it even worse.
Building an extension with --wininst (or any other way) does not package
it with the JCC it was compiled with. And nothing in the package name
tells you whether it was shared or non-shared.
And it makes the build of PyLucene break, since there's still no way to
compile JCC so that it auto-finds the JVM DLL.
If you invoke jcc with --find-jvm-dll, in __main__.py the Path hack is
applied. If it doesn't get there (because that's already too late, the _jcc
extension that pulls in jcc.dll and jvm.dll was already attempted to load
before) then that's a bug. But that's what that code in __main__.py is
supposed to be doing: hack Path so that jcc itself can run.
Andi..
Bill
