[GRASS-dev] grass7 compilation error

[Glynn Clements]

Markus Metz wrote:

> > Also, this issue should only affect code which explicitly includes
> > <grass/config.h> before the system header files, which is a bad idea.
> 
> Why so? Including grass/config.h after all relevant systems headers
> and before all grass headers contradicts current design which
> assumes/requires that grass/config.h is included before some system
> headers.
> 
> In config.h.in, lines 23 to 76, there are, amongst others,
> HAVE_SYS_TYPES_H and HAVE_UNISTD_H (unistd.h maps roughly to io.h on
> mingw). That implies that grass/config.h is supposed to be included
> before these headers (and all headers that pull these in) and that
> these headers should only be included if the corresponding macros are
> set in grass/config.h. Or is this part of config.h.in a remnant from
> old days and is no longer necessary today?

The general sentiment is true; if you need the feature tests, you have
to include <grass/config.h> first. But the entries for <unistd.h> and
<sys/types.h> are pointless; we assume that (unless __MINGW32__ is
defined) you have a system which is at least minimally POSIX
compliant.

In general, you normally include headers in decreasing order of
standard-ness, i.e. ANSI/ISO C headers first, then POSIX headers, then
headers for "core" libraries, then for "add-on" libraries, then the
"common" headers for the package being built, with the headers for the
specific module or subsystem coming last.

Third-party libraries have to accommodate system headers (e.g. not
using variable names which conflict with typedefs in the system
headers), as system headers aren't written to accommodate third-party
libraries.

In that regard, there shouldn't be any reason to include
<grass/config.h> before the most common POSIX headers, and certainly
not before the ANSI/ISO C headers (if you don't have those, GRASS
isn't going to compile).

I'm starting to think that the MinGW-LFS stuff should go at the top of
gis.h, and config.h should be kept conservative (i.e. just defining
ALL_CAPS macros, which are less likely to conflict with anything).

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