[GRASS-dev] Re: [GDAL] #1587: Error compiling gdal-grass against gdal 1.4.1

Hi,

it is currently no more possible to compile the official
GRASS-GDAL-OGR plugin against GRASS 6.3-CVS. There is
a bug report open at GDAL:

http://trac.osgeo.org/gdal/ticket/1587

In summary, there a certain function definition needs
to be conditionalized upon the GRASS version but there
is the problem that it is defined as char in
include/version[.in].

Following question is open:

On Wed, Apr 25, 2007 at 03:58:03PM -0000, GDAL wrote:

#1587: Error compiling gdal-grass against gdal 1.4.1
-------------------------+--------------------------------------------------
Reporter: perrygeo | Owner: mloskot
     Type: defect | Status: reopened
Priority: normal | Milestone:
Component: ConfigBuild | Version: 1.4.1
Severity: normal | Resolution:
Keywords: grass |
-------------------------+--------------------------------------------------
Comment (by mloskot):

Markus,

Would it be possible to have version definition as a preprocessor macro
instead of character object?

Ideally, I think it would be best if there is a version macro defined as a
number calculated as:

{{{
MAJOR * 100000 + MINOR * 100 + MICRO
}}}

what for '''6.3.0''' results as '''600300'''.

This way we have a value that can be easily calculated from version string
and makes it very easy to compare if one version is lower/higher from
another one.

What do you think?

--
Ticket URL: <http://trac.osgeo.org/gdal/ticket/1587#comment:7&gt;
GDAL <http://trac.osgeo.org/gdal/&gt;
Geospatial Data Abstraction Library is a translator library for raster and vector geospatial data formats.

Please suggest - the result should then be posted into the
GDAL bugtracker (you need to register for this, see trac).

Markus

Markus Neteler wrote:

it is currently no more possible to compile the official
GRASS-GDAL-OGR plugin against GRASS 6.3-CVS. There is
a bug report open at GDAL:

http://trac.osgeo.org/gdal/ticket/1587

In summary, there a certain function definition needs
to be conditionalized upon the GRASS version but there
is the problem that it is defined as char in
include/version[.in].

Following question is open:

On Wed, Apr 25, 2007 at 03:58:03PM -0000, GDAL wrote:
> #1587: Error compiling gdal-grass against gdal 1.4.1
> -------------------------+--------------------------------------------------
> Reporter: perrygeo | Owner: mloskot
> Type: defect | Status: reopened
> Priority: normal | Milestone:
> Component: ConfigBuild | Version: 1.4.1
> Severity: normal | Resolution:
> Keywords: grass |
> -------------------------+--------------------------------------------------
> Comment (by mloskot):
>
> Markus,
>
> Would it be possible to have version definition as a preprocessor macro
> instead of character object?
>
> Ideally, I think it would be best if there is a version macro defined as a
> number calculated as:
>
> {{{
> MAJOR * 100000 + MINOR * 100 + MICRO
> }}}
>
> what for '''6.3.0''' results as '''600300'''.
>
> This way we have a value that can be easily calculated from version string
> and makes it very easy to compare if one version is lower/higher from
> another one.
>
> What do you think?
>
> --
> Ticket URL: <http://trac.osgeo.org/gdal/ticket/1587#comment:7&gt;
> GDAL <http://trac.osgeo.org/gdal/&gt;
> Geospatial Data Abstraction Library is a translator library for raster and vector geospatial data formats.

Please suggest - the result should then be posted into the
GDAL bugtracker (you need to register for this, see trac).

I've changed version.h.in so that GRASS_VERSION_* are preprocessor
definitions.

[BTW, we need to decide if GRASS_VERSION_RELEASE is an integer or a
string. AFAICT, it's the actual release number for releases and "cvs"
for the CVS version.]

However, this won't help with previous versions. You could use e.g.

  #include <grass/version.h>

  #ifdef GRASS_VERSION_MAJOR

which will succeed in current versions and fail in older versions.

Alternatively, you can use the following in the Makefile;

  include include/Make/Grass.make

  -DGRASS_VERSION_MAJOR=$(GRASS_VERSION_MAJOR)

But that may not work with non-GNU make utilities, and including the
*.make files is a relatively recent change.

--
Glynn Clements <glynn@gclements.plus.com>