[GRASS-dev] GRASS Make-system question

[Glynn Clements]

Soeren Gebbert wrote:

> >> Can anybody give me a hint how to solve this.
> >
> > Don't try to use quick hacks; do it properly. Either clone the file as
> > e.g. main3.c or make it support both 2d and 3d at run-time.
> 
> Well, actually my intention was not a quick hack. I thought it would
> be meaningful to use macros to reduce the appearance of cloned code
> for easier code maintainability. I did not know that using macros to
> decide at compile time the behavior of a program is a hack at all.

It's not the use of macros that's a hack (there's plenty of code with
conditional sections), but building multiple, distinct object files
from the same source file.

With one exception[1], the GRASS 7.0 build system relies entirely upon
the '%.o: %.c' (etc) pattern rules in Compile.make. This ensures that
any changes to those rules affect everything; there's no need to hunt
down special cases which need to be changed separately (and, in
practice, are likely to be overlooked).

[1] macosx/app/Makefile has an explicit rule for "main.o: main.m".

> I changed the code of r/r3.color.out to meet your guideline.
> 
> I have to rethink the r/r3.colors approach to meet your guideline too,
> but to also reducing cloned code. I am not a fan of cloned code and
> modules with mixed behavior (raster and raster3d support) with the
> need adding scripts to hide there complexity:

If you want distinct modules, make each #ifdef'd chunk into a separate
function, then move those functions into separate source files, one
for 2d and one for 3d.

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