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

[Bernd Zeimetz]

On 2017-01-22 22:53, Fred Wright wrote:
> On Sun, 22 Jan 2017, Bernd Zeimetz wrote:
> > On 01/08/2017 07:14 PM, Jon Schlueter wrote:
> > > I'm thinking right way of fixing this is untangling the qt support so
> > > that all of the at implementations are in one or two CPP files with c
> > > calling function declarations.  That I might be able to refractor in s
> > > couple hours tonight. Keeping code flow the same just moving the c++
> > > isms from at out of the c files, and adjusting scons to match.
> > >
> > > That should clear up a lot of the compile variations. As compiling c
> > > code as c++ across platforms is a dusty corner we want to avoid.
> >
> >
> > To make gpsd build with QT you'll have to use
> > -std=gnu++98
> > (or maybe something else will work, too).
>
> That doesn't seem to be necessary on OSX, where it builds successfully
> with either Qt4 or Qt5, but I'm mostly ignoring Qt issues until I see 
> what
> Jon does.

Wild guess: qt was compiled with the option on linux.

> > And regarding the scons issues: I'd guess I had the issues with scons
> > 2.4, but we have 2.5 in unstable since some months. Guess that 
> > explains
> > why I can't reproduce them in unstable anymore. I'd guess they've 
> > fixed
> > such issues as I'm sure not only gpsd was affected.
>
> Does that include testing with a patch to use the standard CheckFunc?

no. Easy thing to test would be to revert it and wait like 10 minutes,
then a build should show up.

> Since Gary insisted that I unrevert your change in spite of the lack of
> evidence that it's needed, testing with the normal sources doesn't
> currently prove anything with respect to the CheckFunc issue.

I'd say: revert it and see what happens.

> CheckFunc in SCons 2.5 still emits code with the same issues, so if it
> relates to the SCons version that can only mean that there's a 
> difference
> with regard to whether warnings are treated as errors.  But it seems a 
> bit
> far-fetched to suppose that some versions of SCons supply -Werror on 
> their
> own.  Is it possible that the original problem was just a "misleading
> observation", similar to the recently discussed issue where a build
> failure that appeared to be a cleaning problem was actually unrelated 
> to
> cleaning?

Defnitely not, I straced it down to what scons executes / compiles.

--
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F