Andi Vajda <va...@apache.org> wrote: > > > On Tue, 23 Mar 2010, Bill Janssen wrote: > > > Andi Vajda <va...@apache.org> wrote: > > > >>> 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. > >> > >> If you run an extension in shared mode with a different version of jcc > >> than it was compiled against, you'll have crashes and other > >> troubles. You must distribute jcc along with your extension in shared > >> mode. It should be made a dependency, especially on Windows where > >> 'jcc' is explicitely imported to effect the Path hack for finding > >> jcc.dll. > > > > I refuse to believe that egg dependencies work in the real world. It > > seems to me that the right thing to do here is to have the bdist package > > the JCC package with the PyLucene package, in the case where they are > > built shared. That way you know that the PyLucene Windows installer for > > your platform will work. > > A patch fixing this would be welcome.
Unlikely to come from me, though. > >> In non-shared mode, the jcc runtime necessary to run your extension is > >> included in the extension distribution. > > > > Right, and it sounds like it should be included in the shared mode, too. > > On Windows, more than the code is necessary. The whole egg is required > since 'jcc' is imported explicitely at extension import time. Not so > on non-windows. Yes, I think this is an issue with bdist_*, not just PyLucene. I see several possibilities here. One is that the generated setup for PyLucene should just include the whole of the JCC egg, so that it's not a separate egg (on Windows). That seems painful. Another, which is perhaps even more painful, is to build a separate script to build an MSI-style windows installer. To my knowledge, the script used to build Python itself is the only example of such a thing "in the wild", though I intend to do this for the Windows release of UpLib-1.7.9, which is what I'm working on PyLucene for. Just to catch the error, perhaps a hash of the config properties of the JCC used to compile the PyLucene extension could be baked into both, and compared at module load time? Bill
