Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Martin Jansa <martin.jansa@gmail.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: RFC: Separate build dir for autotools
Date: Mon, 24 Feb 2014 16:27:53 +0100	[thread overview]
Message-ID: <20140224152753.GG26981@jama> (raw)
In-Reply-To: <1393253881.31769.6.camel@ted>

[-- Attachment #1: Type: text/plain, Size: 2412 bytes --]

On Mon, Feb 24, 2014 at 02:58:01PM +0000, Richard Purdie wrote:
> For a while poky and others have been using the seperatebuilddir.inc
> file. This makes ${S} != ${B} and means that ${B} can be wiped when
> configuration changes.
> 
> This helps deal with the fact that autotools and friends are not
> particular good at rebuilding things that change. The recent libcheck
> upgrade which broke bluez4 builds is but one example of the kind of
> problem we can hit. Sadly bluez4 doesn't work for S!=B so it didn't
> protect against that issue but it does protect other packages.
> 
> I'd really love to switch the default in autotools.bbclass to make this
> the default and then have broken packages opt out of it.
> 
> I can deal with OE-Core and make sure the metadata there is updated, my
> bigger worry is what this would do to other layers.
> 
> The options I can see are therefore basically:
> 
> a) We change the default in autotools.bbclass and fix things that break

If there is patch to do that, I'm willing to run my world builds with it
to generate updated
www.openembedded.org/wiki/Bitbake_World_Status
so that we have some estimate how many recipes will be broken.

Can we start by adding
include conf/distro/include/seperatebuilddir.inc
to
conf/distro/defaultsetup.conf
? so that more people start using it and possibly report issues in their
builds?

> b) We introduce an "autotools2" class and have recipes inherit that.
> This version would default to separate builddirs. It does mean change to
> all the "good" recipes rather than the broken ones though and hence a
> fair bit of churn.

or introduce "autotools-noseparatebuilddir" as easy to use fix for
broken recipes from a), that will make it easier to search for recipes
to fix (as some kind of janitor task).

> Have we got the willpower to fix a)? is b) an option? Other ideas?

We don't have willpower to fix all issues in Bitbake_World_Status so I
don't expect many people jumping on task of fixing separate B in some
less used recipes/layers (but I can volunteer to replace
"s/autotools/autotools-noseparatebuilddir/g" to keep my World_Status
close to current state).

> One way or another I think we should try and switch things somehow...

Agreed, it went quite smoothly with cmake, qmake5, so autotools is next
:).

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

  parent reply	other threads:[~2014-02-24 15:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-24 14:58 RFC: Separate build dir for autotools Richard Purdie
2014-02-24 15:06 ` Otavio Salvador
2014-02-24 15:27 ` Martin Jansa [this message]
2014-02-24 15:41   ` Burton, Ross
2014-02-24 16:09     ` Martin Jansa
2014-02-24 16:27       ` Richard Purdie
2014-02-26 19:11         ` Martin Jansa
2014-02-26 19:54           ` Burton, Ross
2014-02-26 20:20             ` Phil Blundell
2014-02-25 17:36       ` Nicolas Dechesne
2014-02-25 18:43         ` Burton, Ross
2014-02-25 22:10           ` Nicolas Dechesne
2014-02-26 10:58             ` Nicolas Dechesne
2014-02-25  5:46 ` Khem Raj
2014-02-25  9:52   ` Burton, Ross
2014-02-25 16:32     ` Khem Raj

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=20140224152753.GG26981@jama \
    --to=martin.jansa@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=richard.purdie@linuxfoundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox