Re: [meta-oe][PATCH 4/5] gpsd: add optional support for KPPS interface

[Martin Jansa <martin.jansa@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1784 bytes --]

On Thu, Aug 28, 2014 at 08:05:54AM -0500, Peter A. Bigot wrote:
> On 08/28/2014 07:53 AM, Burton, Ross wrote:
> > On 28 August 2014 13:06, Peter A. Bigot <pab@pabigot.com> wrote:
> >> +PACKAGECONFIG ??= ""
> >> +PACKAGECONFIG[kpps] = ",,pps-tools"
> > That's not actually deterministic - if pps-tools is installed but the
> > packageconfig option is disabled then gpsd will still enable the
> > support.
> 
> Yeah, I'm aware of that.  It's also not something that can be 
> controlled, since gpsd's author doesn't believe in configuration options 
> to enable features: every capability is enabled or disabled by 
> inspecting the environment at compile-time.
> 
> Although ntp does support some explicit enable/disable flags, it too 
> fails to provide a way to say "Pay no attention to that PPS header, it 
> isn't really there."

Then we need to patch their configure.

> For this situation I don't think there's a big issue.  The PACKAGECONFIG 
> setting ensures that the header will be available if the feature is 
> desired.  If it happens to be present but PPS support isn't explicitly 
> requested, there's no failure in either build or runtime: it's still 
> gated by runtime checks for PPS sources and the option being enabled in 
> the Linux kernel.  (There are no runtime libraries that need to be 
> installed to use KPPS.)
> 
> Is this going to be a problem with the patch being accepted?

Yes

people can be used to have KPPS support enabled by "accident" e.g.
because they are building ntp with KPPS support and pps-tools is almost
always built before gpsd..

and then once it's built in different order and end-user will be
surprised by lost KPPS support from gpsd.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]