>> 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.