I tried to synchronize the C code base of relbr6 and devbr6. I did not
port any new functionality to relb6 and did (hopefully) not change
translatable messages.
There are some outstanding issues:
- configure tests for X11/Xmu/Xmu.h in devbr6 (r53778) because it is
required by Nviz. This seems to be true also for relbr6. Backport?
- visualization/nviz backport?
- wxGUI backport?
- ps.map backport?
- d.grid/d.legend/d.text.new backport?
- the scripts differ substantially. Unfortunately, not many people are
testing the scripts in devbr6.
- there are differences in lib/pngdriver and lib/symbol that look like
backport candidates
- v.buffer differs, but is broken in both branches. Only the
GEOS-enabled version in G7 works. Since this is a bugfix, I would
suggest to backport v.buffer from G7 to G6.
2014-04-09 8:28 GMT+02:00 Markus Metz <markus.metz.giswork@gmail.com>:
- wxGUI backport?
will take a look...
[...]
- v.buffer differs, but is broken in both branches. Only the
GEOS-enabled version in G7 works. Since this is a bugfix, I would
suggest to backport v.buffer from G7 to G6.
2014-04-09 8:28 GMT+02:00 Markus Metz <markus.metz.giswork@gmail.com>:
- wxGUI backport?
will take a look...
[...]
- v.buffer differs, but is broken in both branches. Only the
GEOS-enabled version in G7 works. Since this is a bugfix, I would
suggest to backport v.buffer from G7 to G6.
+1
If GEOS thus becomes a mandatory dependency, this will also automatically enable the additional operators in v.select which I think is a good thing.
GEOS is a heavy C++ beast and difficult to compile using GCC
on Windows (at least if you want the result to pass all
validation tests).
I would prefer to stick to C dependencies only for the core
modules, if only to avoid DLL hell when mixing Visual C++
and GCC DLLs on Windows (different name mangling styles).
Ben
On 09/04/14 09:36, Moritz Lennert wrote:
On 09/04/14 08:35, Martin Landa wrote:
Hi Markus,
2014-04-09 8:28 GMT+02:00 Markus Metz <markus.metz.giswork@gmail.com>:
- wxGUI backport?
will take a look...
[...]
- v.buffer differs, but is broken in both branches. Only the
GEOS-enabled version in G7 works. Since this is a bugfix, I would
suggest to backport v.buffer from G7 to G6.
+1
If GEOS thus becomes a mandatory dependency, this will also
automatically enable the additional operators in v.select which I think
is a good thing.
On Wed, 09. Apr 2014 at 10:52:59 +0200, Benjamin Ducke wrote:
GEOS is a heavy C++ beast and difficult to compile using GCC
on Windows (at least if you want the result to pass all
validation tests).
I would prefer to stick to C dependencies only for the core
modules, if only to avoid DLL hell when mixing Visual C++
and GCC DLLs on Windows (different name mangling styles).
That's why GEOS has a C API. Doesn't GRASS use that anyway?
Jürgen
--
Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50
Software Engineer D-26506 Norden http://www.norbit.de
QGIS PSC member (RM) Germany IRC: jef on FreeNode
--
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502
2014-04-09 10:52 GMT+02:00 Benjamin Ducke <benducke@fastmail.fm>:
GEOS is a heavy C++ beast and difficult to compile using GCC
on Windows (at least if you want the result to pass all
validation tests).
I would prefer to stick to C dependencies only for the core
modules, if only to avoid DLL hell when mixing Visual C++
and GCC DLLs on Windows (different name mangling styles).
please note that GEOS is included in OSGeo4W framework. So for G7 it's
compiled with GEOS by default. Martin
2014-04-09 8:35 GMT+02:00 Martin Landa <landa.martin@gmail.com>:
2014-04-09 8:28 GMT+02:00 Markus Metz <markus.metz.giswork@gmail.com>:
- wxGUI backport?
will take a look...
[...]
- v.buffer differs, but is broken in both branches. Only the
GEOS-enabled version in G7 works. Since this is a bugfix, I would
suggest to backport v.buffer from G7 to G6.
agreed.
AFAIK we are close to release 6.4.4, so probably it would be better to
backport these changes after release to have time to test it for
6.4.5. Martin
Has somebody here figured out yet how to compile GEOS
using GCC on Windows (MinGW), so that it passes all of
its own validation tests? That's where I am stuck
at this point:
GEOS is a heavy C++ beast and difficult to compile using GCC
on Windows (at least if you want the result to pass all
validation tests).
I would prefer to stick to C dependencies only for the core
modules, if only to avoid DLL hell when mixing Visual C++
and GCC DLLs on Windows (different name mangling styles).
It's not just name mangling. There isn't an official ABI for C++ on
Windows. Even if all components are compiled with MSVC, simply using
different compiler switches can result in incompatibilities (e.g. the
layout of pointer-to-member values can vary according to the /vm*
switches used).
Different compilers use different mangling rules because their code is
inherently incompatible. Changing the name mangling just prevents
people from trying to do things which aren't going to work anyhow.
And that's why I love this mailing list:
There are insights here that are simply
impossible to get elsewhere. Thanks for
this one, Glynn!
Ben
On 09/04/14 17:18, Glynn Clements wrote:
Benjamin Ducke wrote:
GEOS is a heavy C++ beast and difficult to compile using GCC
on Windows (at least if you want the result to pass all
validation tests).
I would prefer to stick to C dependencies only for the core
modules, if only to avoid DLL hell when mixing Visual C++
and GCC DLLs on Windows (different name mangling styles).
It's not just name mangling. There isn't an official ABI for C++ on
Windows. Even if all components are compiled with MSVC, simply using
different compiler switches can result in incompatibilities (e.g. the
layout of pointer-to-member values can vary according to the /vm*
switches used).
Different compilers use different mangling rules because their code is
inherently incompatible. Changing the name mangling just prevents
people from trying to do things which aren't going to work anyhow.
--
Dr. Benjamin Ducke, M.A.
{*} Geospatial Consultant
{*} GIS Developer
