[meta-intel] [PATCH 3/3] lms: add recipe for lms 1921.0.0.0

[Burton, Ross]

On Mon, 17 Jun 2019 at 13:00, Usyskin, Alexander
<alexander.usyskin at intel.com> wrote:
> > > +inherit cmake systemd pythonnative
> >
> > Does it *really* need python-native?  If it just wants to find a python binary then
> > you can tell it to use the host Python:
> >
> > EXTRA_OECMAKE += "-DPYTHON_EXECUTABLE=${HOSTTOOLS_DIR}/python2"
>
> > Also if this can't use Python 3, which is preferred, then please file a bug
> > upstream to point out that Python 2 is EOL next year.
> >
> I'm the upstream ;)
> And really we need Python3 at build stage. Added EXTRA_OECMAKE, thanks for a tip.

Glad to see you writing recipes, thanks very much!

One less Py2 user is a good thing, we're actively trying to remove it
entirely from oe-core.

> > > +DEPENDS = "metee ace xerces-c libnl libxml2 glib-2.0 glib-2.0-native
> > connman"
> >
> > This build-depends on comman?
> >
> Yes, we using connman dbus interface and build script tries to detect connman availability.

Just looked at the source.  I suggest adding an option for the
networking backend to be used, as OE also has network-manager recipes.

> > > +FILES_${PN} += "${libdir}/*.so"
> > > +FILES_SOLIBSDEV = ""
> > > +INSANE_SKIP_${PN} += "dev-so"
> >
> > So lms is shipping loadable modules directly into /usr/lib?  Have you verified that
> > you're not matching too many files here?  Can you file a bug upstream to follow
> > the best practise of putting them into a subdirectory of $libdir instead of directly
> > in $libdir?
> >
> All loadable libraries are prefixed "lms", so should be unique.
> The modules co-location is the limitation of ACE dynamic loading.

Okay, so how about making the FILES expression ${libdir}/lms*.so to
ensure that you only catch the modules.  Also if they're being shipped
as symlinks to e.g. lcms-foo.so.1 then you should probably fix that to
install directly to the lms-foo.so and that should silence the dev-so
warning.

Ross