gpsd-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Fred Wright
Subject: Re: [gpsd-dev] [PATCH] Fix compiling QT code with at least GCC 6.2.1
Date: Tue, 3 Jan 2017 18:02:19 -0800 (PST)

On Sat, 31 Dec 2016, Robert Norris wrote:

> Use of #ifndef USE_QT in libgpsd_core.c now seems pointless as it will always 
> be TRUE.

Umm, no.  The same sources are compiled twice - once for the "normal"
library, and once for the Qt version.  The former case has that off.

> GPSD seems to have lost the build of a test_qgpsmm program from test_gpsmm.c 
> in the great scons build conversion.

Indeed one of the reasons I've been reluctant to mess with the Qt code is
the inability to test it.  All I did when adding the qt_versioned option
was to make sure it would build.

On Sat, 31 Dec 2016, Jon Schlueter wrote:

> the QT support needs some re-work, as it should not be compiling C code as
> C++.

Well, that's not *always* unreasonable, but whether it's actually
appropriate here needs to be determined.  And if it *is* appropriate, then
something should be done about the clang deprecation warnings that doesn't
involve breaking it for "miscellaneous" compilers.

> But I don't remember enough of the context, I'll try to take a crack at
> re-factoring some
> of the build logic in the New Year.  If there are others who still use it,
> it would be nice to
> make sure I don't break the functionality as I get it rotated into correct
> shape.

Yeah, see above regarding testing. :-)

I don't know how easy and/or helpful it would be to resurrect the
test_qgpsmm program that Rob mentioned.  And license permitting, perhaps
the Qt-based xgps-like program could be pulled into contrib/ to facilitate
testing.

I'll ignore Rob's extern C patch in the meantime, as well as his suggested
"std::" addition.  The latter isn't necessarily bad, since it's inside a
C++ conditional, but it still seems rather unflavorful to have two
different atomic-access methods between C and C++.  More so if the same
data could be accessed by both C and C++.

Fred Wright



reply via email to

[Prev in Thread] Current Thread [Next in Thread]