All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Mikko.Rapeli@bmw.de, openembedded-core@lists.openembedded.org
Subject: Re: [PATCH RFC] insane.bbclass: add buildpaths_cmake and buildpaths_pkgconfig checks
Date: Tue, 25 Sep 2018 12:08:24 +0100	[thread overview]
Message-ID: <576c5e5174123059cfa49e8cf647716497a35610.camel@linuxfoundation.org> (raw)
In-Reply-To: <20180925104443.GP9430@hiutale>

On Tue, 2018-09-25 at 10:44 +0000, Mikko.Rapeli@bmw.de wrote:
> On Tue, Sep 25, 2018 at 01:28:13PM +0300, Mikko Rapeli wrote:
> > And enable them by default as ERROR_QA. Reason is that
> > absolute build directory paths in CMake .cmake modules
> > and in pkg-config .pc files cause recipe builds to escape
> > their recipe specific sysroots and triggers hard to debug
> > and timing sensitive build failures. It's better to fail
> > early.
> > 
> > A failure from sumo version of libical looks like:
> > 
> > ERROR: libical-2.0.0-r0 do_package_qa: QA Issue: CMake module
> > /work/i586-poky-linux/libical/2.0.0-r0/packages-split/libical-
> > dev/usr/lib/cmake/LibIcal/LibIcalTargets-noconfig.cmake contains
> > reference to tmpdir which causes build raceconditions between
> > recipes [buildpaths_cmake]
> > ERROR: libical-2.0.0-r0 do_package_qa: QA run found fatal errors.
> > Please consider fixing them.
> > ERROR: libical-2.0.0-r0 do_package_qa: Function failed:
> > do_package_qa
> > ERROR: Logfile of failure stored in:
> > /home/builder/src/yocto/poky/build/tmp/work/i586-poky-
> > linux/libical/2.0.0-r0/temp/log.do_package_qa.4934
> > NOTE: recipe libical-2.0.0-r0: task do_package_qa: Failed
> > ERROR: Task (/home/builder/src/yocto/poky/meta/recipes-
> > support/libical/libical_2.0.0.bb:do_package_qa) failed with exit
> > code '1'
> > 
> > For some reason libical from poky master branch is not affected.
> 
> The reason why master branch is not affected is:
> 
> commit 26cccb93059b8963651b7d17cea2ee95f52633b7
> Author: Juro Bystricky <juro.bystricky@intel.com>
> Date:   Tue Mar 20 15:36:36 2018 -0700
> 
>     libical-dev_2.0: improve reproducibility
>     
>     Remove build host references from distributed files.
>     
>     (From OE-Core rev: 20f2670e755bcbf90b2b6c08192c022fe7e7eaad)
>     
>     Signed-off-by: Juro Bystricky <juro.bystricky@intel.com>
>     Signed-off-by: Ross Burton <ross.burton@intel.com>
>     Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org
> >
> 
> diff --git a/meta/recipes-support/libical/libical_2.0.0.bb
> b/meta/recipes-support/libical/libical_2.0.0.
> index dcc21cc..daa47ab 100644
> --- a/meta/recipes-support/libical/libical_2.0.0.bb
> +++ b/meta/recipes-support/libical/libical_2.0.0.bb
> @@ -17,3 +17,10 @@ SRC_URI[sha256sum] =
> "654c11f759c19237be39f6ad401d917e5a05f36f1736385ed958e60cf2
>  UPSTREAM_CHECK_URI = "https://github.com/libical/libical/releases"
>  
>  inherit cmake pkgconfig
> +
> +do_install_append_class-target () {
> +    # Remove build host references
> +    sed -i \
> +       -e 's,${STAGING_LIBDIR},${libdir},g' \
> +       ${D}${libdir}/cmake/LibIcal/LibIcalTargets-noconfig.cmake
> +}
> 
> Now I'm struggling horribly with the same problem in various custom
> CMake modules, so how about doing that same STAGING_LIBDIR to libdir
> switch for all CMake modules automatically in cmake.bbclass?
> 
> I tried to correctly fix the libical CMake files too with help from
> #cmake, but eventually had to give up. libical has an embedded
> FindICU.cmake module but it seems like the upstream FindICU.cmake
> ends
> up producing the same absolute paths while it does fix some other
> bugs, and of course introduces new ones like no longer providing
> ICU_I18N_FOUND variable when i18n ICU module is found.

I suspect we need to talk to cmake upstream about fixing this properly
but adding something in the class may be an option until a better
upstream solution can be found.

I am puzzled by the need to add a .pc file path check since I thought
there was already a test for that in insane.bbclass?

package_qa_check_staged maybe? "Check staged la and pc files for common
problems like references to the work directory."

Cheers,

Richard










  reply	other threads:[~2018-09-25 11:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-25 10:28 [PATCH RFC] insane.bbclass: add buildpaths_cmake and buildpaths_pkgconfig checks Mikko Rapeli
2018-09-25 10:44 ` Mikko.Rapeli
2018-09-25 11:08   ` Richard Purdie [this message]
2018-09-25 11:21     ` Mikko.Rapeli
2018-09-25 15:19       ` richard.purdie
2018-09-25 17:11         ` Mikko.Rapeli
2018-09-25 18:29           ` richard.purdie
2018-09-25 20:28             ` Mikko.Rapeli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=576c5e5174123059cfa49e8cf647716497a35610.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=Mikko.Rapeli@bmw.de \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.