Re: [gpsd-dev] [PATCH] Fix compiling QT code with at least GCC 6.2.1

[Fred Wright]

On Fri, 30 Dec 2016, Robert Norris wrote:

> Inclusion of the "compiler.h" must be outside of extern C scope,
>  otherwise the C++ compiler may throw errors such like:
> "error: template with C linkage"
>
> Hence close and reopen the extern scope surrounding the use of compiler.h
>  in gpsd.h which itself gets included in C++ code.

Closing and reopening the extern C seems rather kludgy, but admittedly
this is all rather a mess.

If there's to be only one compiler.h, then it should work for both C and
C++, and should be included in whichever context is appropriate.  The
alternative would be to have separate versions for C and C++.  But setting
up definitions for one language and then building for another seems like
it's asking for trouble.

The current handling of "atomic" seems rather messy.  Given that GPSD is
pure C code with some wrappers for C++ callability, it seems weird to use
a C++-only feature in the core code.

The Qt build uses a mixture of C and C++ compiles for the libgps code.
Six of the 20 sources are compiled as C, while the other 14 (C) sources
are compiled as C++.  One of the effects of this is to get 14 deprecation
warnings from recent versions of clang.  I'm not sure why any of it has to
be compiled as C++; maybe it's a namespacing issue.  The recommended way
to get rid of the warning on C->C++ compiles is to include "-x c", but
that's not entirely portable (it's probably valid across the entire
gcc/llvm/clang family, but it wasn't hard to find references to a compiler
where "-x" does something entirely different).

The non-Qt libgpsmm just adds a single C++ compile to libgps and leaves
the rest as C.  If libQgpsmm could get away with doing the same it would
sure make things simpler.

Fred Wright