Andi Vajda <va...@apache.org> wrote: > > 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.
OK, I'll look harder at why that isn't working. Bill
