Paul Kelly wrote:
I will try and answer the first question: Off the top of my head here are
some things that should be fixed:
1) Remove gdalbridge code from r.in.gdal
Agree.
2) Update internal GRASS PROJ library to remotesensing.org proj apart from
the local bugfixes (in this case disable the --with-proj option so we have
to use the internal fixed version) *and/or* change modules that convert
projected co-ordinates to lat/long to use pj_latlong_from_proj() function
(to workaround PROJ bug number 368
http://bugzilla.remotesensing.org/show_bug.cgi?id=368 )
No opinion.
3) Fix up glX dependencies in NVIZ
Agree.
(really I'm not too sure about the
status of this; probably good to release and let the bug reports flow in)
Disagree. The problems are known; either fix the code or revert to a
previous version.
4) Fix conditional compilation of g3d modules for glX dependencies and
other variable OpenGL stuff
Agree. AFAICT, this just requires that r3.showdspf.openGL is removed
from src.contrib/GMSL/g3d/src3d/raster/Gmakefile and added as a
separate module via LOC_OPTIONAL in configure.in.
5) Various updates for v.in.dxf and v.in.dxf3d: an option to write to
category labels to dig_cats instead of dig_atts. Also some fixes people
have sent in should be merged (e.g. I remember something 8-bit character
encoding)
No opinion.
6) r.terraflow should only be compiled if g++ is detected; it won't work
with any other C++ compiler
Unsure.
The gratuitous gcc-isms should be removed from the Gmakefile; it
should also be fixed to work with the alternate build system (note
that this probably precludes building both short and float versions).
Apart from that, many of the incompatibilities seem to arise from
requiring near-complete ANSI C++ conformance. Particularly regarding
templates, which were one of the later features to be standardised by
ANSI, and were the main source of non-conformance for gcc 2.9x.
Unless we can identify problems which are definitely due to gcc-isms,
and we can't easily fix them, we should probably leave it up to the
user to decide whether to attempt to build C++ modules (i.e.
r.terraflow; I hope that anyone else who was considering using C++ has
come to their senses by now).
The only was that we will find out if other C++ compilers work is if
people can actually try using them. Forcibly disabling C++ programs if
!$(GCC) will make that rather difficult.
7) Make --enable-gmake=no the default and use the alternate build
mechanism for shared libraries---this needs a few changes for Cygwin.
Maybe dig2 and vect libraries merged into one big library? Or else
compiled as static library. Also driverlib compiled statically.
Unsure.
It seems a bit risky at this stage, given how little testing it has
received (AFAIK).
I suspect that Cygwin will require more than a few changes. Windows
DLLs are very different from shared libraries.
But yes of course we can release now and put off these fixes until 5.3.1.
And I can probably do the release though it would take me a while. I would
need some instructions on how to sign the source code tarball (and
possibly the binaries).
I suggest omitting some of the more problematic changes. The "flash"
feature in d.what.* springs immediately to mind.
More generally, I suggest that someone posts a full summary of changes
since 5.0.3 for comments. For most of those changes, testing won't
have extended beyond two (probably quite similar) Linux/x86 systems.
--
Glynn Clements <glynn.clements@virgin.net>