the last time I ended up in the hell of mixing libraries built using
mingw (GRASS) and msvs (wxpython). Currently I have no time for this
kind of "fun". If somebody put on wiki instructions how to overcome
this problem I will be happy to fix MS Windows related bugs to make
these extensions working under MS Windows.
have you tried the updated & simplified build instructions using osgeo4w
as the framework?
the last time I ended up in the hell of mixing libraries built using
mingw (GRASS) and msvs (wxpython). Currently I have no time for this
kind of "fun". If somebody put on wiki instructions how to overcome
this problem I will be happy to fix MS Windows related bugs to make
these extensions working under MS Windows.
have you tried the updated & simplified build instructions using osgeo4w
as the framework?
sure, I followed these instructions - but it doesn't help you to make
the Python extensions working (swig-related failure - probably because
wxPython is built using msvs and GRASS with mingw).
On Wed, Jun 17, 2009 at 5:30 AM, Hamish<hamish_b@yahoo.com> wrote:
Martin wrote:
the last time I ended up in the hell of mixing libraries built using
mingw (GRASS) and msvs (wxpython). Currently I have no time for this
kind of "fun". If somebody put on wiki instructions how to overcome
this problem I will be happy to fix MS Windows related bugs to make
these extensions working under MS Windows.
have you tried the updated & simplified build instructions using osgeo4w
as the framework?
If I'm understanding correctly, the OSGeo4W framework appears to be
part of the problem as those packagers used msvc rather than mingw to
compile several of the libraries.
Last night I compiled wxwidgets with mingw (though python and swig are
still msvc I think), which gave me a wx-config file to use in the
grass configure (trunk and devbr_6). During make, errors popped up for
xganim but not for vdigit. However, neither worked when I tested the
builds. Probably because i left out --with-cxx which I didn't realize
was required, and --with-python which I haven't been able to figure
out from the lists if its required or not. I should read the build
instructions more carefully. Was I missing anything else?
-Colin
then hopefully it is mostly a matter of making sure the PATH order is
correct. (??)
>> the last time I ended up in the hell of mixing libraries built using
>> mingw (GRASS) and msvs (wxpython). Currently I have no time for this
>> kind of "fun". If somebody put on wiki instructions how to overcome
>> this problem I will be happy to fix MS Windows related bugs to make
>> these extensions working under MS Windows.
>
> have you tried the updated & simplified build instructions using osgeo4w
> as the framework?
>
> https://trac.osgeo.org/grass/wiki/CompileOnWindows
If I'm understanding correctly, the OSGeo4W framework appears to be
part of the problem as those packagers used msvc rather than mingw to
compile several of the libraries.
The main problem which I had was that the stock Windows wxPython
distribution doesn't include a wx-config file, and the third-party
Windows wx-config project doesn't appear to be compatible with the
wxPython version which I have (2.8.9.2).
I would strongly prefer to use the stock package rather than a custom
version, to prevent conflicts.
Last night I compiled wxwidgets with mingw (though python and swig are
still msvc I think), which gave me a wx-config file to use in the
grass configure (trunk and devbr_6). During make, errors popped up for
xganim but not for vdigit. However, neither worked when I tested the
builds. Probably because i left out --with-cxx which I didn't realize
was required, and --with-python which I haven't been able to figure
out from the lists if its required or not. I should read the build
instructions more carefully. Was I missing anything else?
--with-python is required.
I just tried using it with MinGW, but the check failed due to warnings
about redefining HAVE_PUTENV and HAVE_FTIME (autoconf's include checks
fail if the preprocessor writes anything to stderr, regardless of the
exit code).
Hacking pyconfig.h allowed configure to progress further, although
python-config can't seem to figure out CFLAGS etc.