gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] Bernd's CheckFunc Fix


From: Fred Wright
Subject: Re: [gpsd-dev] Bernd's CheckFunc Fix
Date: Sun, 8 Jan 2017 00:34:45 -0800 (PST)

On Sat, 7 Jan 2017, Jon Schlueter wrote:
> On Sat, Jan 7, 2017 at 9:26 PM, Fred Wright <address@hidden> wrote:
> > On Sat, 7 Jan 2017, Jon Schlueter wrote:
> >> On Fri, Jan 6, 2017 at 7:02 PM, Fred Wright <address@hidden> wrote:
> >> > On Fri, 6 Jan 2017, Bernd Zeimetz wrote:
> >> >> On 01/04/2017 02:56 AM, Fred Wright wrote:
> >> >> > I just did in the interests of expediency, but as yet there's no 
> >> >> > evidence
> >> >> > that anyone other than Bernd sees the problem that the extra 50 lines 
> >> >> > of
> >> >> > code are trying to fix.
> >> >>
> >> >> ... right now it fails to build while including compiler.h.
> >> >
> >> > That's the known issue with the Qt build, which I've been ignoring since
> >> > Jon said he was going to look into it.  It has nothing to do with
> >> > CheckFunc.  What happens when you build with qt=no?
> >>
> >>
> >> Looking closer at how the QT support was hacked in, I'm inclined to
> >> either re-write
> >> it and correctly extract the c++ isms that are scattered through the C
> >> code, or drop the qt support all together if we don't have an active
> >> developer to maintain it.
> >
> > Dropping it altogether seems overly heavy-handed.  If it's too broken to
> > leave enabled, then I'd suggest downgrading it to "experimental" and
> > making qt=no the default.  That way, anyone who wants to can still "use at
> > own risk", but the default build isn't broken.  Though just making it
> > build shouldn't be too hard.
>
> Yea, I have a re-producer environment now for what Bernd was seeing,
> I'll see if I can work any magic on it.

By "what Bernd was seeing" do you mean the Qt build problem mentioned
above?  I can reproduce it on at least one VM here, though not with the
native Mac build.  Adding "std::" as Rob suggested indeed makes that
problem go away, and then exposes the one related to C vs. C++ for the
compiler.h include.  I looked at that a bit, and my inclination would be
to move the compiler.h include to be before the conditional extern C
(i.e., in "head"  rather than "tail"), rather than closing and reopening
the latter.  This doesn't fix the more general "messy Qt C/C++" issues,
but may be enough to make it build, anyway.  It also leaves open the issue
of whether mixing different "atomic strategies" between C and C++ is
appropriate.

Unless we can come up with a reasonable way to test the Qt code, it might
be a good idea to provide an "as is" notification in the docs.

None of this has anything to do with CheckFunc, of course, or even SCons
for that matter.

Fred Wright



reply via email to

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