RE: [GRASS5] What's holding 5.3.0 release?

GRASS GRASS developer
,
1

The last month I received several comments telling that the current
situation of GRASS development for new programmers is confusing.

In fairness to you, Markus, I think the discussions on this list made
it clear what the plan is and what the differences between the versions
are.

Having said that, I do have questions about proj4 and r.in.gdal.

My understanding is that the proj4 library is not required for 5.3.
An internal version will be used if not found BUT there is a slight
difference in the versions and a small bug has been fixed in the
grass supplied version. This this correct and does it affect the
release of 5.3? Have we documented the difference?

For r.in.gdal, I made a small attempt to understand why some
people were having seg-fault problems. I still don't understand
this. Is there a difference in r.in.gdal in 5.3? A recent problem
was fixed, I think, relating to DEMS. Is this in the 5.3 version?

And I just remembered r.terraflow. Is that fixed to compile on
gcc 2.9x and >3.x now? I don't see it in the man pages for 5.3 on the
web. Will it be included for 5.3? I assume not.

(I am trying to be helpful here, not a nuisance.)

John

2

John Gillette wrote:

For r.in.gdal, I made a small attempt to understand why some
people were having seg-fault problems. I still don't understand
this.

That's OK; nor does anyone else :wink:

Seriously, there are a variety of reasons why r.in.gdal segfaults;
some of those reasons are better understood than others.

Some specifics which increase the likelyhood of r.in.gdal working are:

1. Using --with-gdal, so libgdal is linked directly rather than loaded
dynamically with dlopen().

2. Building GDAL with the --without-grass switch.

Is there a difference in r.in.gdal in 5.3?

Only that --with-gdal is now the default.

--
Glynn Clements <glynn.clements@virgin.net>

3

And I just remembered r.terraflow. Is that fixed to compile on
gcc 2.9x and >3.x now? I don't see it in the man pages for 5.3 on the
web. Will it be included for 5.3? I assume not.

It should be working now, please test.

You are likely to see some "depreciated" messages, but there's not much
we can do about that without breaking compatibility with gcc 2.95s.

... having said that ...

I think the best way to fix it is as Laura suggested, to use the
shortened include names if gcc version>=3.2, and in all other cases (and
compilers) use full <name.h>. Someone with gcc 3.0 might tell us if it
includes <ostream> so we can get the minor version correct?

#if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
#include <ostream>
#else
#include <ostream.h>
#endif

etc

This should make it compile cleanly for both gcc 2.95 and 3.x and fix
the error Paul saw using IRIX's CC:
  http://article.gmane.org/gmane.comp.gis.grass.devel/2896

e.g. a test for gcc version >=3.1,

#include <stdio.h>

int main(void) {

#if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
    printf("new gcc version %d.%d\n", __GNUC__, __GNUC_MINOR__);
#else
    printf("not a modern gcc\n");
#endif

    return 0;
}

regards,
Hamish

4

On Sat, 31 Jan 2004, Glynn Clements wrote:

John Gillette wrote:

> For r.in.gdal, I made a small attempt to understand why some
> people were having seg-fault problems. I still don't understand
> this.

That's OK; nor does anyone else :wink:

Seriously, there are a variety of reasons why r.in.gdal segfaults;
some of those reasons are better understood than others.

Some specifics which increase the likelyhood of r.in.gdal working are:

1. Using --with-gdal, so libgdal is linked directly rather than loaded
dynamically with dlopen().

2. Building GDAL with the --without-grass switch.

> Is there a difference in r.in.gdal in 5.3?

Only that --with-gdal is now the default.

Also: last week I removed an erroneous free() call, which perhaps has the
potential to clear up a lot of obscure problems.

5

On Fri, Jan 30, 2004 at 04:29:21PM -0500, John Gillette wrote:

> The last month I received several comments telling that the current
> situation of GRASS development for new programmers is confusing.

In fairness to you, Markus, I think the discussions on this list made
it clear what the plan is and what the differences between the versions
are.

Well, the differences between 5.0-5.3-5.7 are quite clear to me.
In fact I was posting comments from other potential developers.
What the plan is, is fairly undefined in terms of time.

What we need, is a list of items, or, preferred, a voting system
to get out releases more frequently.

My experience to get out 5.0.3 was not very satisfying (see ML archive).

But of course just my 0.3 Euro

Markus

6

Hamish wrote:

I think the best way to fix it is as Laura suggested, to use the
shortened include names if gcc version>=3.2, and in all other cases (and
compilers) use full <name.h>. Someone with gcc 3.0 might tell us if it
includes <ostream> so we can get the minor version correct?

gcc 3.0.3 has <ostream>.

#if __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)

This should probably be either:

#if !defined(__GNUC__) || __GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)

or:

#if defined(__GNUC__) && (__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1))

depending upon whether we want other compilers to use <ostream> or
<ostream.h>.

--
Glynn Clements <glynn.clements@virgin.net>