[colord] Intent of lib{huey,dtp94,munki}

[Christopher James Halse Rogers]

On Thu, 2013-02-07 at 09:02 +0000, Richard Hughes wrote:
> On 7 February 2013 03:23, Christopher James Halse Rogers
> <chris at cooperteam.net> wrote:
> > I'm wondering what the intent of the huey, dtp94, and munki libs are, under
> > libs/?
> 
> Device access libs -- if you were writing a tool to target a specific
> instrument you would link against these. I use them for my reverse
> engineering tools.
> 
> > They look like convenience libraries, as they don't install headers and are
> > used only in the sensor plugins, but they get compiled as a real shared
> > library and installed into /usr/lib.
> 
> I think these need to be a real shared library, as they are linked in
> from the sensor drivers, the daemon and various other utilities in the
> project. I don't think a noinst_lib file cuts it, although if you can
> get this working I guess it's fine for me.
> 
> > Having libraries in /usr/lib without an accompanying development header
> > package seems icky to me.
> 
> I know what you mean. What about if they were called libhuey-private.so etc?
> 
Yeah, that might be better.

> > It looks like they might be potentially useful
> > outside of colord, so they could ship the headers. If not, could we just
> > build them into the sensor plugins?
> 
> The idea was that I could trivially add a .pc file and install the
> headers if anyone asked. There are a few projects with very incomplete
> instrument driver code, and if they wanted to use the raw driver code
> in colord I'd be really happy to add the required bits. I didn't see
> any point installing headers that were not going to be used.

That seems reasonable. I'll put a notice in README.Debian so if anyone
looks for the sources there's a pointer here.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/colord/attachments/20130208/027c9424/attachment.html>