|
From: | Jon Schlueter |
Subject: | Re: [gpsd-dev] [PATCH] Fix compiling QT code with at least GCC 6.2.1 |
Date: | Sat, 31 Dec 2016 18:38:17 -0500 |
>> 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.
It's Qt all the way down - mainly using Qt network functions in libgps_core.c
It mostly stems from commit d8462cfb9ef84e1b0fbd7c794993318d56bd6dfc back in 2010.
Thus providing portability to other OS's (OS X + Windows) supported by the Qt framework for gpsd clients (if one can actually build the gpsd code in the right manner...).
Use of #ifndef USE_QT in libgpsd_core.c now seems pointless as it will always be TRUE.
(Not sure why it is trying to prevent some logging but not others).
GPSD seems to have lost the build of a test_qgpsmm program from test_gpsmm.c in the great scons build conversion.
--
Be Seeing You - Rob.
If at first you don't succeed,
then skydiving isn't for you.From: gpsd-dev <gpsd-dev-bounces+rw_norris=hoaddress@hidden > on behalf of Fred Wright <address@hidden>
Sent: 30 December 2016 23:37:27
To: address@hidden
Subject: Re: [gpsd-dev] [PATCH] Fix compiling QT code with at least GCC 6.2.1
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
[Prev in Thread] | Current Thread | [Next in Thread] |