[GRASS-dev] endian & generic library

[Glynn Clements]

Brad Douglas wrote:

> Understood re: endian programming issues.  Should it go into SUBMITTING?

SUBMITTING isn't supposed to be a tutorial on C programming (even if
many contributors badly need one).

> Does it make sense to have these functions, string/debug, and memory
> related functions in a separate library?  More trouble than it's worth?

I'm not sure that a library makes sense; it's probably better for
import/export modules to do it themselves. Apart from anything else,
it allows the compiler to inline the code; such modules will typically
be [de]serialising arrays rather than individual integers.

> I think we could benefit from having a small library (libcommon?) that
> all libraries would link against (where appropriate), rather than having
> a number of libraries link to libgis or duplicate efforts where it
> really isn't necessary.

Anything which is part of GRASS should link against libgis for core
functionality such as memory allocation, error handling, accessing
files within the database directory, etc. There aren't many cases
where a program which doesn't use anything from libgis warrants being
included as part of GRASS.

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