[GRASSLIST:2198] Re: new module compilation problems

[Glynn Clements]

chiara.sboarina at katamail.com wrote:

> I'm trying to transform a program, that calculates forest carbon fluxes, 
> in a GRASS module. I have rewritten the main code file and modified some 
> other code files but when I try to compile it I get some errors. I can't 
> understand how to correct errors because many of them are in lines with 
> GRASS libraries. I report the compiler error lines and a piece of the 
> program.
> 
> main.c:30: parse error before `{'
> main.c:27: parm types given both in parmlist and separately
> main.c:154: `argv' undeclared (first use in this function)
> main.c:154: (Each undeclared identifier is reported only once
> main.c:154: for each function it appears in.)
> main.c:157: warning: assignment from incompatible pointer type
> main.c:158: dereferencing pointer to incomplete type
> 
> 
> #include "gis.h"
> #include <stdlib.h>
> #include <stdio.h>
> #include <math.h>
> #include <malloc.h>
> #include <string.h>
> #include <time.h>

I suggest that you include gis.h *after* you have included the system
headers. gis.h may define macros which interfere with the parsing of
the system headers. More on this below.

Also, I suggest that you check the "bgc" headers for anything which
might cause problems. The fact that you get an error right at the
start of your code suggests that there may be an error there, such as
an unterminated brace.

[The following is a general summary of common issues regarding the use
of header files.]

In general, headers should be included in order from most general to
most specific, i.e.:

1. ANSI C headers (stdio.h etc)

2. Non-ANSI OS headers (unistd.h etc)

3. General external libraries (X11, curses, etc)

4. External libraries which are more specific to the project (e.g. for
a GRASS module, this would include external GIS-related libraries).

5. Libraries which are part of the project (gis.h etc for a GRASS
module).

6. Headers which are part of the actual module (e.g. the local_proto.h
used by many GRASS modules).

Because C doesn't have a formal module system or namespaces, you have
to be careful to avoid the situation where one header defines
something which affects the interpretation of a subsequent header
(preprocessor macros are particularly bad, but typedefs can also cause
problems).

As a general rule, the more widely-used a particular header is, the
more care will be taken not to add unnecessary definitions, and the
more likely that other, less widely-used headers will avoid
conflicting definitions.

A concrete example: the geodesic.h file from the PROJ library defines
macros called "a", "S" and "f":

	# define a	GEODESIC.A
	...
	# define S	GEODESIC.DIST
	# define f	GEODESIC.FLAT

If you were to include geodesic.h before other headers, there is a
good chance that they will fail; e.g. if a subsequent header declared:

	struct foo {
		int a;
	...

this would get expanded to:

	struct foo {
		int GEODESIC.A;

which is a syntax error.

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