gpsd-dev
[Top][All Lists]
Advanced

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

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


From: Gary E. Miller
Subject: Re: [gpsd-dev] [PATCH 1/2] Moves Linux-only ppscheck program back to contrib/.
Date: Mon, 8 Aug 2016 15:59:36 -0700

Yo Fred!

On Sat, 6 Aug 2016 09:47:13 -0700 (PDT)
Fred Wright <address@hidden> wrote:

> 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).

If you thin of a move as a copy/delete then we are talking the same thing.

> > 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.

Yup, and I'm gonna spend the time, when I get it, if no one beats me to it.

I'm sure you could make a patch in less time that your email took to write.

> The priority should be unbreaking the build ASAP.

Yup.  But not by trading one breakage for another.

> 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.

I can;t test everthing, and I'm pretty sure I did not break all non-Linux
builds.

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

Which only applies after you know what may cause 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.

Got proof that is not true?  If so, I'll take a patch to fix it.

> In the case of clock_gettime(), I believe that 

Belief is not a proof.  And how about we worry about making it
portable instead of worrying about water over the dam.

> 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.

I'll take a patch.

> 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.

Which is sort that point?  To test the modem control signals!

> Meanwhile, let's just fix the build, and worry about convenience of
> building ppscheck later.

I'll take patches, as long as the do not break the new functionality
where it is currently working.

> BTW, my second patch is unrelated.

I've been out for 3 days, prolly gonna be out another day, so nothing
gets patched until I get caught up.

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

Attachment: pgpGMi7fJYgxn.pgp
Description: OpenPGP digital signature


reply via email to

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