[GRASS5] working on g3d

Glynn Clements glynn.clements at virgin.net
Fri Feb 28 01:46:10 EST 2003


Markus Neteler wrote:

> > The main problem is figuring out how to use the same source code to
> > build two separate programs. Ideally, the build process for
> > src/raster/r.mapcalc3 wouldn't require any changes. Options for
> > handling this include:
> 
> Note (you will know that already, Glynn):

Actually I didn't.

> r.terraflow is building two versions from shared code with compile flags.

I use the alternate build system almost exclusively[1], so r.terraflow
doesn't build anything; it just fails because r.terraflow/Gmakefile
(uniquely) has its own compilation rules.

[1] The only exception is if I specifically want to test the "normal"
build system.

r.terraflow/Gmakefile also relies upon features of GNU make, so it
won't work with other make programs.

BTW, has anyone tried building r.terraflow on anything other than
Linux?

> > 1. Build the common parts of r.mapcalc as a library, which both
> > r.mapcalc and r3.mapcalc use.
> 
> Maybe yes, and this code might be interesting for other modules
> as well (r.neighbors etc).

The code in question isn't really useful for anything other than
r.mapcalc/r3.mapcalc.

> > 2. Requires that the (optional) g3d library was built before
> > r.mapcalc.
> 
> which should be no big issue as it does not have external
> dependencies (hope I am right).

OK; actually g3d isn't optional. s.vol.rst is built by default, and
s.vol.rst/Gmakefile specifically builds src/libes/g3d.

So, making r.mapcalc depend upon g3d is technically feasible. Although
whether it's a good idea is a different question. Doing so would
effectively turn g3d into core functionality.

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




More information about the grass-dev mailing list