Re: ✘ Release blockers?

[Gary E. Miller]

Yo Fred!

On Wed, 18 Dec 2019 21:51:16 -0800 (PST)
Fred Wright <address@hidden> wrote:

> On Wed, 18 Dec 2019, Bernd Zeimetz wrote:
> > On 2019-12-18 10:02, Fred Wright wrote:  
> >>>  We do test on clang.  I test on osX which uses clang.  But I see
> >>> I do not have Qt enabled.  Not sure how to do that on a mac.  
> >>
> >>  If you have MacPorts installed, just install the qt4-mac port.
> >> At one time I also had builds with Qt5 working on the Mac, but
> >> something changed that broke it since then, so for now it's
> >> Qt4-only.  
> >
> > qt4 is deprecated and should be gone for good for a long time.
> > Nothing serious should use it anymore.  
> 
> It's better than not testing the Qt code on the mac at all.

No.  It is easy to test the code tor Qt5 on osX.  Qt4 is not even
available anymore.  Qt5 is very broken on osX.  Since we seem to have
no one that cares about Qt5, especially Qt5 on the mac, it is OK to be
broken.

To test Qt5 on osX:

    # port install scons
    # port install git
    # port install libxslt
    # port install xmlto
    # port install qt5
    # scons --config=force qt_versioned=5

Then the warnings/errors are numerous:

[...]
g++ -o qt-gpsutils.os -c -pthread -Wall -Wcast-align -Wextra 
-Wimplicit-fallthrough -Wno-missing-field-initializers -Wno-uninitialized 
-Wpointer-arith -Wreturn-type -Wvla -O2 -fPIC -DUSE_QT -DQT_NETWORK_LIB 
-DQT_CORE_LIB -I/opt/local/include/dbus-1.0 -I/opt/local/lib/dbus-1.0/include 
-I/opt/local/libexec/qt5/lib/QtNetwork.framework/Headers 
-I/opt/local/libexec/qt5/include 
-I/opt/local/libexec/qt5/lib/QtCore.framework/Headers 
-F/opt/local/libexec/qt5/lib gpsutils.c
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is 
deprecated [-Wdeprecated]
In file included from gpsutils.c:31:
In file included from 
/opt/local/libexec/qt5/lib/QtCore.framework/Headers/QDateTime:1:
In file included from 
/opt/local/libexec/qt5/lib/QtCore.framework/Headers/qdatetime.h:44:
In file included from /opt/local/libexec/qt5/include/QtCore/qstring.h:48:
In file included from /opt/local/libexec/qt5/include/QtCore/qchar.h:43:
In file included from /opt/local/libexec/qt5/include/QtCore/qglobal.h:105:
/opt/local/libexec/qt5/include/QtCore/qcompilerdetection.h:564:6: error: Qt 
requires a C++11 compiler and yours does not seem to be that.
#    error Qt requires a C++11 compiler and yours does not seem to be that.
[...]

Maybe easy to fix.  Out of my area of knowledge.

Pathes welcome.  Not gonnna wait for them.

> > there is something completely broken. Not sure what you are trying
> > to fix there. Note the 'if c_only in qt_flags' line.
> >
> > So what did you actually try to do here? Guess you had a reason for
> > that change?  
> 
> Nope.  Brain fart.  That's what I get for hurrying (while also having
> a remove() failure on the brain from another place).  It is actually
> more efficient to use the try/except *instead of* the if when the
> item has a high probability of being present, but the if is more
> compact, and of course it makes no sense to do both.  Reverted.

I'm confused.  Back where we started.  Not gonna worry about it.

> >    https://en.wikipedia.org/wiki/PowerPC#Endian_modes
> >
> > Selectable.  Sometimes on a per page level.  
> 
> Read it again.  Particularly the parts about "The processor starts in 
> big-endian mode" and the "warped view" needed for little-endian mode.

Yeah, I read that.  Not what you said.  Glad we agree wikipedia is correct.

>  In any case, my information is baed on the actual PowerPC specs from
> Motorola and IBM, not Wikipedia.

Citations always welcome.  Preferably when you make a dubious claim.

> > Sadly that is the world we live in today.  I run into this
> > constantly on Gentoo unstable that loves to update the compilers
> > frequently. 
> >> I'd like to try to fix that before the release.  
> >
> > The world would appreciate that, but not a gpsd issue.  
> 
> Actually it is.  There's nothing that says that Python extensions
> need to be built with the same compiler as Python itself, but the
> GPSD build procedure thinks that they do.  Unfortunately, a quick
> experiment at fixing that proved unsuccessful, so I guess that bug
> will have to wait.

Until you find where SConstruct enforce that, you'll have to take my word
for it that it is not in there.  Feel free to prove me wrong.

> I actually don't see any value in changing the name in the JSON at
> all, since hardly anyone looks at the JSON directly and changing the
> name breaks compatibility.  What would make more sense would be to
> keep the old name on the wire and have the client libraries pass it
> along under both names, with the old one being labeled deprecated.
> That not only keeps compatibility on the wire, but also avoids
> breaking existing clients. These are public libraries, so there can
> be other programs that use them besides the ones bundled with GPSD,
> and those shouldn't be expected to be updated in lockstep with GPSD
> releases.

gpsd has NEVER worked compatibly between releases.  A nice goal, but
we'll never get there.

Plus, I'm not sure what change you disliked...

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgpHqnHPVu8Ht.pgp
Description: OpenPGP digital signature