[yocto] Antwort: Re: how to configure the build packages of a makefile based libary

[Burton, Ross]

Hi Stefan,

So close :)  Some more points:

On 29 April 2016 at 08:54, <S.Jaritz at esa-grimma.de> wrote:
> LICENSE = "COPYING"

This should be the name of the license itself, not the filename.  Looks a
bit like MIT to me.

> LIC_FILES_CHKSUM =
"file://${WORKDIR}/git/COPYING;md5=d84d659a35c666d23233e54503aaea51"

This URI is relative to ${S} so you can just do file://COPYING;md5=....

> EXTRA_OEMAKE = "'PREFIX=/usr/'"

Use PREFIX=${prefix} to respect the what the distro has configured.
Annoyingly you can't override the other paths such a libdir easily, so this
will break in multilib configurations or if I recall correctly, on aarch64.

The commandline outputs:
> #############
> NOTE: Executing RunQueue Tasks
> WARNING: QA Issue: libhiredis: /libhiredis-staticdev/usr/lib/libhiredis.a
> is owned by uid 1000, which is the same as the user running bitbake. This
> may be due to host contamination [host-user-contaminated]
> WARNING: QA Issue: libhiredis: /libhiredis/usr/lib/libhiredis.so.0.13 is
> owned by uid 1000, which is the same as the user running bitbake. This may
> be due to host contamination [host-user-contaminated]
> WARNING: QA Issue: libhiredis:
> /libhiredis-dev/usr/lib/pkgconfig/hiredis.pc is owned by uid 1000, which is
> the same as the user running bitbake. This may be due to host contamination
> [host-user-contaminated]
> #############
>

The upstream Makefile is using "cp -a" which preserves ownership, so as you
built the package the files are owned by you.  Luckily you can override
this by passing "INSTALL='cp -r' to the make install (they use cp to
recursively copy directories, so you need to pass -r instead).

I've a recipe locally with these changes and it builds without warnings and
is packaged correctly.

This is what happens when maintainers think autotools is too complicated
and a bare makefile is just fine: they do it wrong. :)

Ross
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20160429/539a2b5d/attachment.html>