[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