Re: [gpsd-dev] [PATCH 1/2] Moves Linux-only ppscheck program back to contrib/.

[Fred Wright]

On Fri, 5 Aug 2016, Gary E. Miller wrote:

> It is too important to just remove.

This patch doesn't "remove" it; it just *moves* it (back to where it was).

> Got a patch that selectively compiles only on Linux?  Or, better yet, a
> patch to make it work on more OS?

Those things are possible, but with more work and hence more time.  The
priority should be unbreaking the build ASAP.  Breaking all non-Linux
builds just so that a small subset of Linux users have a slightly easier
way to run a program that they can still run when it's in contrib/ doesn't
seem like a good tradeoff.

Software development should obey the Hippocratic oath:  "First do no
harm."

This issue might be partly Eric's fault, due to the following highly
misleading comment in ppscheck.c:

 * This code requires only ANSI/POSIX. If it doesn't compile and run
 * on your Unix there is something very wrong with your Unix.

In the case of clock_gettime(), I believe that that function is *now* part
of POSIX, but it's fairly recent and not necessarily present in all
"POSIX-compliant" OSes.  In fact, OSX is one of the few OSes that's
actually passed the official POSIX compliance test suite, and yet it lacks
that call.  Even in Linux, only fairly recent versions of libc include it;
otherwise you get link errors if you don't include "-lrt".

It's not even clear why clock_gettime was used here, since its only value
over the much more portable gettimeofday() is the nanosecond resolution,
and it's extremely unlikely that you're going to get sub-microsecond
timing accuracy without kernel timestamping, anyway.  However, gpsd
already has clock_gettime.c to handle the portability issue, so it could
be applied here as well.

TIOCMIWAIT is another story.  AFAICT it doesn't exist on any platform
other than Linux, and ppsthread.c seems to have quite a bit of code
associated with working around its unavailability.  In hindsight, it might
have been better to make the code in ppsthread.c usable in a standalone
program, which would not only avoid maintaining two separate sets of PPS
code, but also ensure that any bugs in the PPS handling behaved
consistently between the test program and gpsd itself.  But I suspect that
the current code isn't amenable to that approach.

There's also the matter of testing.  It requires a serial adapter with a
full complement of modem-control signals, and driver support in all
supported OSes.  It also requires a GPS receiver lame enough to use a
modem-control line for PPS, or some other serial-line PPS test setup.

Meanwhile, let's just fix the build, and worry about convenience of
building ppscheck later.  Someone incapable of cd'ing to contrib/ and
running "scons ppscheck" is probably a lost cause, anyway. :-)

BTW, my second patch is unrelated.

Fred Wright