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 <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
