You are viewing a plain text version of this content. The canonical link for it is here.
Posted to pylucene-dev@lucene.apache.org by Bill Janssen <ja...@parc.com> on 2010/03/18 21:56:50 UTC
building pylucene with mingw
OK, now I'm stymied by PyLucene itself.
/c/Python26/python.exe -m jcc.__main__ --shared ... --build
needs to know that we're using the mingw32 compiler. It doesn't seem to
remember it, which I guess is the right solution, so I wind up with the
same problem:
error: Unable to find vcvarsall.bat
And there's no way (I can see) to tell jcc about that compiler, is there?
Bill
Re: building pylucene with mingw
Posted by Bill Janssen <ja...@parc.com>.
Andi Vajda <va...@apache.org> wrote:
>
> On Mar 20, 2010, at 18:41, Bill Janssen <ja...@parc.com> wrote:
>
> > Andi,
> >
> > Do you run what's called these days a continuous integration server?
> > We
> > use Hudson to continuously test UpLib, and find it very handy. I
> > presume
> > the ASF has such a setup somewhere. Since you've already got a set of
> > tests for pylucene, it would be simple to set up a server to run those
> > tests every time you make a change. It's almost ridiculously easy to
> > do with Hudson, once you've got the tests written.
>
> No, I don't. I know Lucene does, so it's possible. What problem would
> this be solving in the context of PyLucene/JCC ? How can it be
> achieved without creating extra work ?
Sorry, unsolicited advice. :-) And there's no problem I'm aware of,
it's just a QA thing.
I was just thinking that I always hate to make changes without testing
it on all platforms, especially in code where there's a lot of "if
sys.platform == ..." tests. This is a lot easier to do with some kind
of buildbot setup. If you have the tests already written (as you have),
and a Hudson installation available, with test slaves for the various
platforms, it's remarkably easy. Takes only a small shell script to set
up an all-platforms test which is triggered every time a change is made
to the Subversion or CVS repository. Hudson checks out the code, and
runs the shell script on it.
In my case, I've already got UpLib tests, and build scripts for the
three OS platforms I support, so my test script comes down to something
like
$ svn update
$ [set up paths to pick a particular compiler/Java/Python combo]
$ [pick and run platform-specific build script]
$ UPLIBRC=`pwd`/tests/tests.uplibrc make test
Bill
Re: building pylucene with mingw
Posted by Andi Vajda <va...@apache.org>.
On Mar 20, 2010, at 18:41, Bill Janssen <ja...@parc.com> wrote:
> Andi,
>
> Do you run what's called these days a continuous integration
> server? We
> use Hudson to continuously test UpLib, and find it very handy. I
> presume
> the ASF has such a setup somewhere. Since you've already got a set of
> tests for pylucene, it would be simple to set up a server to run those
> tests every time you make a change. It's almost ridiculously easy to
> do with Hudson, once you've got the tests written.
No, I don't. I know Lucene does, so it's possible. What problem would
this be solving in the context of PyLucene/JCC ? How can it be
achieved without creating extra work ?
Andi..
>
> Bill
Re: building pylucene with mingw
Posted by Andi Vajda <va...@apache.org>.
On Fri, 19 Mar 2010, Bill Janssen wrote:
> Bill Janssen <ja...@parc.com> wrote:
>
>> Andi Vajda <va...@apache.org> wrote:
>>
>>>
>>> On Thu, 18 Mar 2010, Bill Janssen wrote:
>>>
>>>> Hmmm, setuptools doesn't seem to know to automatically build the jcc.lib
>>>> file when using mingw32.
>>>
>>> You might need to change the platform test there to include the 'mingw32'
>>> value or add the specific code to do this next to the 'win32' case.
>>>
>>> If you don't, then just kwds["extra_link_args"] = lflags is done.
>>>
>>> Andi..
>>
>> OK, I'll add the link flags in setup.py, and send you a patch against
>> the trunk.
>
> Attached is the patch to Makefile and jcc/setup.py, generated with svn
> diff, against the trunk.
No attachment was received here.
Andi..
>
> I've tested it by building and installing on Windows XP with MinGW32 gcc
> 4.4.
>
Re: building pylucene with mingw
Posted by Bill Janssen <ja...@parc.com>.
Bill Janssen <ja...@parc.com> wrote:
> Andi Vajda <va...@apache.org> wrote:
>
> >
> > On Thu, 18 Mar 2010, Bill Janssen wrote:
> >
> > > Hmmm, setuptools doesn't seem to know to automatically build the jcc.lib
> > > file when using mingw32.
> >
> > You might need to change the platform test there to include the 'mingw32'
> > value or add the specific code to do this next to the 'win32' case.
> >
> > If you don't, then just kwds["extra_link_args"] = lflags is done.
> >
> > Andi..
>
> OK, I'll add the link flags in setup.py, and send you a patch against
> the trunk.
Attached is the patch to Makefile and jcc/setup.py, generated with svn
diff, against the trunk.
I've tested it by building and installing on Windows XP with MinGW32 gcc 4.4.
Bill
Re: on Windows, getting the JVM DLL on your Path automatically
Posted by Bill Janssen <ja...@parc.com>.
Andi Vajda <va...@apache.org> wrote:
> We disagree here and since you want this, you can turn it on.
As long as I can turn it on, I'm happy. But your other users will still
have this rather hard-to-understand hurdle to jump. Maybe there could
be a better error message that explains it? I wonder if Python has any
way to try to load a DLL?
Something like this:
try:
from jcc import _jcc
except ImportError, x:
if sys.platform == "win32":
try:
from ctypes import windll
except:
# probably an older Python
raise x
else:
try:
windll.LoadLibrary("jvm.dll")
except WindowsError, x:
if x.winerror == 126:
print """
The JVM DLL could not be loaded. Make sure the location is on your Path
environment variable.
"""
> Nothing worse debugging building with one VM and running with another
> unwittingly.
Presumably the dynamic linker protects us from ABI mismatches... right?
But, of course, this is a common problem on Windows, so common that
there's a name for it, "DLL hell"... and so common that it might not
make sense to try to protect people from it here :-).
Bill
Re: on Windows, getting the JVM DLL on your Path automatically
Posted by Andi Vajda <va...@apache.org>.
On Mar 19, 2010, at 19:52, Bill Janssen <ja...@parc.com> wrote:
> Andi Vajda <va...@apache.org> wrote:
>
>> On Fri, 19 Mar 2010, Bill Janssen wrote:
>>
>>> I see we're still not doing this:
>>>
>>> http://www.mail-archive.com/pylucene-dev@osafoundation.org/msg02204.html
>>>
>>> That is, lucene or jcc or whatever fails to load because the
>>> location of
>>> jvm.dll isn't on the value of the user's "Path" environment
>>> variable.
>>>
>>> What if I submitted a patch? I keep tripping over this darned bug.
>>
>> I sure don't want to mess with people's Path behind their backs.
>
> You're already doing this in jcc/__init__.py, so don't be too
> pure :-).
>
>> If you can do this with yet another command line option used at jcc
>> invocation to cause it to add this to the __init__.py file, then
>> sure.
>
> Yes, that makes sense. Or perhaps in the initVM, with an optional
> parameter to enable or disable it. That way it could be controlled by
> an individual program, regardless of how the default was compiled in.
>
>> But it's got to be off by default.
>
> Just to bikeshed a bit, having it be off by default doesn't make much
> sense to me; you'd have the same problem you have now.
No no, you have this problem, not me :-).
> It should be on
> by default, and there should be a way to disable it, for people who
> are
> doing things with the PATH.
We disagree here and since you want this, you can turn it on. Nothing
worse debugging building with one VM and running with another
unwittingly.
> As I discuss in the thread referenced above (and generally agreed to
> by
> the participants in that thread), it would goes at the end of the
> path, so
> it's a backstop.
>
> And maybe we're going at this the wrong way. Maybe I should just
> get -R
> or -rpath working with the mingw ld.
That would be best, of course.
Andi..
>
> Bill
Re: on Windows, getting the JVM DLL on your Path automatically
Posted by Bill Janssen <ja...@parc.com>.
Andi Vajda <va...@apache.org> wrote:
> On Fri, 19 Mar 2010, Bill Janssen wrote:
>
> > I see we're still not doing this:
> >
> > http://www.mail-archive.com/pylucene-dev@osafoundation.org/msg02204.html
> >
> > That is, lucene or jcc or whatever fails to load because the location of
> > jvm.dll isn't on the value of the user's "Path" environment variable.
> >
> > What if I submitted a patch? I keep tripping over this darned bug.
>
> I sure don't want to mess with people's Path behind their backs.
You're already doing this in jcc/__init__.py, so don't be too pure :-).
> If you can do this with yet another command line option used at jcc
> invocation to cause it to add this to the __init__.py file, then
> sure.
Yes, that makes sense. Or perhaps in the initVM, with an optional
parameter to enable or disable it. That way it could be controlled by
an individual program, regardless of how the default was compiled in.
> But it's got to be off by default.
Just to bikeshed a bit, having it be off by default doesn't make much
sense to me; you'd have the same problem you have now. It should be on
by default, and there should be a way to disable it, for people who are
doing things with the PATH.
As I discuss in the thread referenced above (and generally agreed to by
the participants in that thread), it would goes at the end of the path, so
it's a backstop.
And maybe we're going at this the wrong way. Maybe I should just get -R
or -rpath working with the mingw ld.
Bill
Re: on Windows, getting the JVM DLL on your Path automatically
Posted by Andi Vajda <va...@apache.org>.
On Fri, 19 Mar 2010, Bill Janssen wrote:
> I see we're still not doing this:
>
> http://www.mail-archive.com/pylucene-dev@osafoundation.org/msg02204.html
>
> That is, lucene or jcc or whatever fails to load because the location of
> jvm.dll isn't on the value of the user's "Path" environment variable.
>
> What if I submitted a patch? I keep tripping over this darned bug.
I sure don't want to mess with people's Path behind their backs.
If you can do this with yet another command line option used at jcc
invocation to cause it to add this to the __init__.py file, then sure. But
it's got to be off by default.
Andi..
on Windows, getting the JVM DLL on your Path automatically
Posted by Bill Janssen <ja...@parc.com>.
I see we're still not doing this:
http://www.mail-archive.com/pylucene-dev@osafoundation.org/msg02204.html
That is, lucene or jcc or whatever fails to load because the location of
jvm.dll isn't on the value of the user's "Path" environment variable.
What if I submitted a patch? I keep tripping over this darned bug.
Bill
Re: building pylucene with mingw
Posted by Bill Janssen <ja...@parc.com>.
Bill Janssen <ja...@parc.com> wrote:
> Bill Janssen <ja...@parc.com> wrote:
>
> > I see some code in distutils.cygwinccompiler that seems to point the
> > way. In the twisted world of Distutils/Setuptools, the way you address
> > issues like this is to generate a subclass of, in this case,
> > distutils.cygwincompiler.Mingw32CCompiler, and then monkeypatch
> > disutils.cygwincompiler so that your subclass becomes the actual class.
>
> OK, I tried this, and it seems to work. jcc.lib is created, and installed
> in the same place that jcc.dll is installed.
>
> But jcc/_jcc.lib is also created; the link command doesn't distinguish
> between extensions and libraries. That's not a problem, but it is ugly.
I can fix that by only generating .lib for .dll output files.
Bill
Re: building pylucene with mingw
Posted by Bill Janssen <ja...@parc.com>.
Bill Janssen <ja...@parc.com> wrote:
> I see some code in distutils.cygwinccompiler that seems to point the
> way. In the twisted world of Distutils/Setuptools, the way you address
> issues like this is to generate a subclass of, in this case,
> distutils.cygwincompiler.Mingw32CCompiler, and then monkeypatch
> disutils.cygwincompiler so that your subclass becomes the actual class.
OK, I tried this, and it seems to work. jcc.lib is created, and installed
in the same place that jcc.dll is installed.
But jcc/_jcc.lib is also created; the link command doesn't distinguish
between extensions and libraries. That's not a problem, but it is ugly.
Bill
Re: building pylucene with mingw
Posted by Andi Vajda <va...@apache.org>.
On Mar 18, 2010, at 18:18, Bill Janssen <ja...@parc.com> wrote:
> Andi Vajda <va...@apache.org> wrote:
>
>>
>> On Thu, 18 Mar 2010, Bill Janssen wrote:
>>
>>> Andi Vajda <va...@apache.org> wrote:
>>>
>>>>>> If you don't, then just kwds["extra_link_args"] = lflags is done.
>>>>
>>>>> I've still got to manually copy the .lib file in order to build
>>>>> PyLucene, but otherwise it seems to work. I'm working on
>>>>> getting the
>>>>> .lib file automatically in the right place.
>>>>
>>>> Yes, that's been a lingering bug of this for a long time. That
>>>> jcc.lib
>>>> file doesn't make it over the first time.
>>>
>>> What's got me stumped is figuring out how to preduct where
>>> setuptools
>>> will require it to be after installation. That must be predictable
>>> from some aspect of setuptools, but after an hour of plunking around
>>> in the source, I don't see just how that's generated.
>>
>> it's done by the linker because of this in setup.py:
>> "/IMPLIB:%s" %(os.path.join('jcc', jcclib))
>
> But that just gives you "jcc/jcc.lib". It's the path that's
> interesting.
Yes, and I remember trying hard to figure out a better path but it I
eventually gave up. There didn't seem to be a good way to get a the
path to put this into the right place in the build tree :(
Andi..
>
> I see some code in distutils.cygwinccompiler that seems to point the
> way. In the twisted world of Distutils/Setuptools, the way you
> address
> issues like this is to generate a subclass of, in this case,
> distutils.cygwincompiler.Mingw32CCompiler, and then monkeypatch
> disutils.cygwincompiler so that your subclass becomes the actual
> class.
>
> In this case, the subclass would override the link() method, and
> extend
> objects with the appropriate filename:
>
> Here's a direct quote from that code:
>
> # we want to put some files in the same directory as the
> # object files are, build_temp doesn't help much
> # where are the object files
> temp_dir = os.path.dirname(objects[0])
> # name of dll to give the helper files the same base name
> (dll_name, dll_extension) = os.path.splitext(
> os.path.basename(output_filename))
>
> # generate the filenames for these files
> def_file = os.path.join(temp_dir, dll_name + ".def")
> [...]
> objects.append(def_file)
>
> So I'd do the same for jcc.lib:
>
> lib_file = os.path.join(temp_dir, dll_name + ".lib")
> # now make sure setuptools knows to include it
> objects.append(lib_file)
>
> And add
>
> # generate .lib file for the .pyd
> extra_preargs.append("-Wl,--out-implib,%s" % lib_file)
>
> to the "extra_preargs". That should create jcc.lib in the correct
> place, but that seems to be the only way of getting my hands on the
> generated location, and of telling setuptools to put that file in the
> egg.
>
> On the other hand, it should work :-). I'll try it tomorrow.
>
> Bill
Re: building pylucene with mingw
Posted by Andi Vajda <va...@apache.org>.
On Fri, 19 Mar 2010, Bill Janssen wrote:
> Bill Janssen <ja...@parc.com> wrote:
>
>> But that just gives you "jcc/jcc.lib". It's the path that's interesting.
>
> Andi, why are you putting it in the "jcc" subdirectory? Shouldn't it be
> in the same place the jcc.dll file is? I see that the generated code for
> jcc thinks it should go in the "jcc" subdir, but that doesn't seem right
> to me.
Because it's a datafile that is needed when JCC is used to compile extension
modules on Windows. More precisely, it's needed by the linker. But the file
needs to be installed by distutils/setuptools and is hence put into the
jcc's package_data dir, rooted on the 'jcc' tree.
Andi..
Re: building pylucene with mingw
Posted by Bill Janssen <ja...@parc.com>.
Andi Vajda <va...@apache.org> wrote:
>
> On Thu, 18 Mar 2010, Bill Janssen wrote:
>
> > Andi Vajda <va...@apache.org> wrote:
> >
> >>>> If you don't, then just kwds["extra_link_args"] = lflags is done.
> >>
> >>> I've still got to manually copy the .lib file in order to build
> >>> PyLucene, but otherwise it seems to work. I'm working on getting the
> >>> .lib file automatically in the right place.
> >>
> >> Yes, that's been a lingering bug of this for a long time. That jcc.lib
> >> file doesn't make it over the first time.
> >
> > What's got me stumped is figuring out how to preduct where setuptools
> > will require it to be after installation. That must be predictable
> > from some aspect of setuptools, but after an hour of plunking around
> > in the source, I don't see just how that's generated.
>
> it's done by the linker because of this in setup.py:
> "/IMPLIB:%s" %(os.path.join('jcc', jcclib))
But that just gives you "jcc/jcc.lib". It's the path that's interesting.
I see some code in distutils.cygwinccompiler that seems to point the
way. In the twisted world of Distutils/Setuptools, the way you address
issues like this is to generate a subclass of, in this case,
distutils.cygwincompiler.Mingw32CCompiler, and then monkeypatch
disutils.cygwincompiler so that your subclass becomes the actual class.
In this case, the subclass would override the link() method, and extend
objects with the appropriate filename:
Here's a direct quote from that code:
# we want to put some files in the same directory as the
# object files are, build_temp doesn't help much
# where are the object files
temp_dir = os.path.dirname(objects[0])
# name of dll to give the helper files the same base name
(dll_name, dll_extension) = os.path.splitext(
os.path.basename(output_filename))
# generate the filenames for these files
def_file = os.path.join(temp_dir, dll_name + ".def")
[...]
objects.append(def_file)
So I'd do the same for jcc.lib:
lib_file = os.path.join(temp_dir, dll_name + ".lib")
# now make sure setuptools knows to include it
objects.append(lib_file)
And add
# generate .lib file for the .pyd
extra_preargs.append("-Wl,--out-implib,%s" % lib_file)
to the "extra_preargs". That should create jcc.lib in the correct
place, but that seems to be the only way of getting my hands on the
generated location, and of telling setuptools to put that file in the
egg.
On the other hand, it should work :-). I'll try it tomorrow.
Bill
Re: building pylucene with mingw
Posted by Andi Vajda <va...@apache.org>.
On Thu, 18 Mar 2010, Bill Janssen wrote:
> Andi Vajda <va...@apache.org> wrote:
>
>>>> If you don't, then just kwds["extra_link_args"] = lflags is done.
>>
>>> I've still got to manually copy the .lib file in order to build
>>> PyLucene, but otherwise it seems to work. I'm working on getting the
>>> .lib file automatically in the right place.
>>
>> Yes, that's been a lingering bug of this for a long time. That jcc.lib
>> file doesn't make it over the first time.
>
> What's got me stumped is figuring out how to preduct where setuptools
> will require it to be after installation. That must be predictable
> from some aspect of setuptools, but after an hour of plunking around
> in the source, I don't see just how that's generated.
it's done by the linker because of this in setup.py:
"/IMPLIB:%s" %(os.path.join('jcc', jcclib))
Andi..
Re: building pylucene with mingw
Posted by Bill Janssen <ja...@parc.com>.
Andi Vajda <va...@apache.org> wrote:
> >> If you don't, then just kwds["extra_link_args"] = lflags is done.
>
> > I've still got to manually copy the .lib file in order to build
> > PyLucene, but otherwise it seems to work. I'm working on getting the
> > .lib file automatically in the right place.
>
> Yes, that's been a lingering bug of this for a long time. That jcc.lib
> file doesn't make it over the first time.
What's got me stumped is figuring out how to preduct where setuptools
will require it to be after installation. That must be predictable
from some aspect of setuptools, but after an hour of plunking around
in the source, I don't see just how that's generated.
Bill
Re: building pylucene with mingw
Posted by Andi Vajda <va...@apache.org>.
On Thu, 18 Mar 2010, Bill Janssen wrote:
> Andi Vajda <va...@apache.org> wrote:
>
>>
>> On Thu, 18 Mar 2010, Bill Janssen wrote:
>>
>>> Hmmm, setuptools doesn't seem to know to automatically build the jcc.lib
>>> file when using mingw32.
>>
>> You might need to change the platform test there to include the 'mingw32'
>> value or add the specific code to do this next to the 'win32' case.
>>
>> If you don't, then just kwds["extra_link_args"] = lflags is done.
>>
>> Andi..
>
> OK, I'll add the link flags in setup.py, and send you a patch against
> the trunk.
>
> I've still got to manually copy the .lib file in order to build
> PyLucene, but otherwise it seems to work. I'm working on getting the
> .lib file automatically in the right place.
Yes, that's been a lingering bug of this for a long time. That jcc.lib file
doesn't make it over the first time.
> I'll send you a patch for the PyLucene Makefile to add this build case
> to the list, as well.
>
> I notice that the HTML documentation file for JCC doesn't mention the
> --compiler flag, but it is in the docstring generated for the jcc
> module.
Yeah, that doc keeps getting out of date. A good resource for the command
line flags is:
python -m jcc.__main__ --help
I try to keep these current.
Andi..
Re: building pylucene with mingw
Posted by Bill Janssen <ja...@parc.com>.
Andi Vajda <va...@apache.org> wrote:
>
> On Thu, 18 Mar 2010, Bill Janssen wrote:
>
> > Hmmm, setuptools doesn't seem to know to automatically build the jcc.lib
> > file when using mingw32.
>
> You might need to change the platform test there to include the 'mingw32'
> value or add the specific code to do this next to the 'win32' case.
>
> If you don't, then just kwds["extra_link_args"] = lflags is done.
>
> Andi..
OK, I'll add the link flags in setup.py, and send you a patch against
the trunk.
I've still got to manually copy the .lib file in order to build
PyLucene, but otherwise it seems to work. I'm working on getting the
.lib file automatically in the right place.
I'll send you a patch for the PyLucene Makefile to add this build case
to the list, as well.
I notice that the HTML documentation file for JCC doesn't mention the
--compiler flag, but it is in the docstring generated for the jcc
module.
Bill
Re: building pylucene with mingw
Posted by Andi Vajda <va...@apache.org>.
On Thu, 18 Mar 2010, Bill Janssen wrote:
> Hmmm, setuptools doesn't seem to know to automatically build the jcc.lib
> file when using mingw32.
You might need to change the platform test there to include the 'mingw32'
value or add the specific code to do this next to the 'win32' case.
If you don't, then just kwds["extra_link_args"] = lflags is done.
Andi..
Re: building pylucene with mingw
Posted by Bill Janssen <ja...@parc.com>.
Hmmm, setuptools doesn't seem to know to automatically build the jcc.lib
file when using mingw32.
Bill
Re: building pylucene with mingw
Posted by Andi Vajda <va...@apache.org>.
On Thu, 18 Mar 2010, Bill Janssen wrote:
> Andi Vajda <va...@apache.org> wrote:
>
>>
>> On Thu, 18 Mar 2010, Bill Janssen wrote:
>>
>>> Ah! "--compiler mingw32", instead of "--compiler=mingw32".
>>>
>>> Great, thanks. This is all coming back to me (slowly)...
>>>
>>> I think this is something else that JCC should remember and apply
>>> automatically. What do you think?
>>
>> Remember how ? from what ? You want jcc to invoke the compiler, tell it
>> which one via --compiler.
>
> JCC always has to invoke *some* compiler, to compile the stubs that it
> generates. Right?
Not necessarily, you could drive that compilation yourself. But I see your
point.
> The question is, must it always use the same
> compiler that JCC itself was compiled with?
On windows, probably. Elsewhere, I'm not so sure.
> And I think the answer is, no. You can compile JCC with VS and you get a
> standard Python extension, albeit needing to link against some compatible
> JVM DLL. You can then take that extension and move it to a machine without
> VS, but having MinGW, and use it to generate and compile stubs for some
> Java jar file, using MinGW as the compiler. I think.
>
>>> Suppose I build a Windows installer for JCC with mingw32. Should
>>> that work with Visual Studio, if unpacked on a machine that doesn't
>>> have mingw32 but does have Visual Studio? In which case the option
>>> should stay explicit, instead of remembered, I suppose.
>
> As I outline above.
>
>> I have no idea. This is so over my head...
>
> I always feel like I'm banging my head against the wall, getting things
> done on Windows the hard way, but people are clamoring for a Windows
> installer for UpLib, so...
I feel your pain.
Andi..
Re: building pylucene with mingw
Posted by Bill Janssen <ja...@parc.com>.
Andi Vajda <va...@apache.org> wrote:
>
> On Thu, 18 Mar 2010, Bill Janssen wrote:
>
> > Ah! "--compiler mingw32", instead of "--compiler=mingw32".
> >
> > Great, thanks. This is all coming back to me (slowly)...
> >
> > I think this is something else that JCC should remember and apply
> > automatically. What do you think?
>
> Remember how ? from what ? You want jcc to invoke the compiler, tell it
> which one via --compiler.
JCC always has to invoke *some* compiler, to compile the stubs that it
generates. Right? The question is, must it always use the same
compiler that JCC itself was compiled with? And I think the answer is,
no. You can compile JCC with VS and you get a standard Python
extension, albeit needing to link against some compatible JVM DLL.
You can then take that extension and move it to a machine without VS,
but having MinGW, and use it to generate and compile stubs for some
Java jar file, using MinGW as the compiler. I think.
> > Suppose I build a Windows installer for JCC with mingw32. Should
> > that work with Visual Studio, if unpacked on a machine that doesn't
> > have mingw32 but does have Visual Studio? In which case the option
> > should stay explicit, instead of remembered, I suppose.
As I outline above.
> I have no idea. This is so over my head...
I always feel like I'm banging my head against the wall, getting things
done on Windows the hard way, but people are clamoring for a Windows
installer for UpLib, so...
Bill
Re: building pylucene with mingw
Posted by Andi Vajda <va...@apache.org>.
On Thu, 18 Mar 2010, Bill Janssen wrote:
> Ah! "--compiler mingw32", instead of "--compiler=mingw32".
>
> Great, thanks. This is all coming back to me (slowly)...
>
> I think this is something else that JCC should remember and apply
> automatically. What do you think?
Remember how ? from what ? You want jcc to invoke the compiler, tell it
which one via --compiler.
> Suppose I build a Windows installer for JCC with mingw32. Should
> that work with Visual Studio, if unpacked on a machine that doesn't
> have mingw32 but does have Visual Studio? In which case the option
> should stay explicit, instead of remembered, I suppose.
I have no idea. This is so over my head...
Andi..
>
> Bill
>
>
> Andi Vajda <va...@apache.org> wrote:
>
>>
>> On Thu, 18 Mar 2010, Bill Janssen wrote:
>>
>>> OK, now I'm stymied by PyLucene itself.
>>>
>>> /c/Python26/python.exe -m jcc.__main__ --shared ... --build
>>>
>>> needs to know that we're using the mingw32 compiler. It doesn't seem to
>>> remember it, which I guess is the right solution, so I wind up with the
>>> same problem:
>>>
>>> error: Unable to find vcvarsall.bat
>>>
>>> And there's no way (I can see) to tell jcc about that compiler, is there?
>>
>> Have you tried --compiler ?
>>
>> Andi..
>
>
Re: building pylucene with mingw
Posted by Bill Janssen <ja...@parc.com>.
Ah! "--compiler mingw32", instead of "--compiler=mingw32".
Great, thanks. This is all coming back to me (slowly)...
I think this is something else that JCC should remember and apply
automatically. What do you think?
Suppose I build a Windows installer for JCC with mingw32. Should
that work with Visual Studio, if unpacked on a machine that doesn't
have mingw32 but does have Visual Studio? In which case the option
should stay explicit, instead of remembered, I suppose.
Bill
Andi Vajda <va...@apache.org> wrote:
>
> On Thu, 18 Mar 2010, Bill Janssen wrote:
>
> > OK, now I'm stymied by PyLucene itself.
> >
> > /c/Python26/python.exe -m jcc.__main__ --shared ... --build
> >
> > needs to know that we're using the mingw32 compiler. It doesn't seem to
> > remember it, which I guess is the right solution, so I wind up with the
> > same problem:
> >
> > error: Unable to find vcvarsall.bat
> >
> > And there's no way (I can see) to tell jcc about that compiler, is there?
>
> Have you tried --compiler ?
>
> Andi..
Re: building pylucene with mingw
Posted by Andi Vajda <va...@apache.org>.
On Thu, 18 Mar 2010, Bill Janssen wrote:
> OK, now I'm stymied by PyLucene itself.
>
> /c/Python26/python.exe -m jcc.__main__ --shared ... --build
>
> needs to know that we're using the mingw32 compiler. It doesn't seem to
> remember it, which I guess is the right solution, so I wind up with the
> same problem:
>
> error: Unable to find vcvarsall.bat
>
> And there's no way (I can see) to tell jcc about that compiler, is there?
Have you tried --compiler ?
Andi..