[GRASS5] What's holding 5.3.0 release?

[Glynn Clements]

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 at virgin.net>