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 <[email protected]> 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: [email protected]
signature.asc
Description: Digital signature
-- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
