RFC: Separate build dir for autotools

RFC: Separate build dir for autotools

[Richard Purdie]

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

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.

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

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

Cheers,

Richard

Re: RFC: Separate build dir for autotools

[Otavio Salvador]

Hello Richard,

On Mon, Feb 24, 2014 at 11:58 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> 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

+1

I think it is better to fix this sooner than later. This indeed helps
improve the build stability so I think this is better to default to
the better options; adding an extra class for it is the wrong way in
my point of view and we'll "support" the wrong use of it. I think the
exceptions are better covered if we keep it explicit in a var and easy
to spot in a git grep.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: RFC: Separate build dir for autotools

[Martin Jansa]

[-- 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 --]

Re: RFC: Separate build dir for autotools

[Burton, Ross]

On 24 February 2014 15:27, Martin Jansa <martin.jansa@gmail.com> wrote:
> 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?

That list is opt-in and mainly covers oe-core, so this gets tested
every time the YP autobuilder does a world build.  We need a meta-oe
world build where autotools.bbclass sets B="${WORKDIR}/build": it's
literally just this one-line patch.

I guess a good first step would be to make this change in oe-core and
do a world build there, adding explicit B=$S statements to any recipes
that break with B!=S.

Ross

Re: RFC: Separate build dir for autotools

[Martin Jansa]

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

On Mon, Feb 24, 2014 at 03:41:11PM +0000, Burton, Ross wrote:
> On 24 February 2014 15:27, Martin Jansa <martin.jansa@gmail.com> wrote:
> > 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?
> 
> That list is opt-in and mainly covers oe-core, so this gets tested
> every time the YP autobuilder does a world build.  We need a meta-oe
> world build where autotools.bbclass sets B="${WORKDIR}/build": it's
> literally just this one-line patch.

But doesn't cover oe-core built with different combinations for
PACKAGECONFIGs, .bbappends etc, so including this file in
defaultsetup.conf can still reveal few issues in oe-core recipes.

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

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

Re: RFC: Separate build dir for autotools

[Richard Purdie]

On Mon, 2014-02-24 at 17:09 +0100, Martin Jansa wrote:
> On Mon, Feb 24, 2014 at 03:41:11PM +0000, Burton, Ross wrote:
> > On 24 February 2014 15:27, Martin Jansa <martin.jansa@gmail.com> wrote:
> > > 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?
> > 
> > That list is opt-in and mainly covers oe-core, so this gets tested
> > every time the YP autobuilder does a world build.  We need a meta-oe
> > world build where autotools.bbclass sets B="${WORKDIR}/build": it's
> > literally just this one-line patch.
> 
> But doesn't cover oe-core built with different combinations for
> PACKAGECONFIGs, .bbappends etc, so including this file in
> defaultsetup.conf can still reveal few issues in oe-core recipes.

Patch out for testing, I'll merge it if nobody objects...

Cheers,

Richard

Re: RFC: Separate build dir for autotools

[Khem Raj]

On Mon, Feb 24, 2014 at 6:58 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> 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

This would be sort of late call for 1.6 IMO but I would prefer this solution.

>
> 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.

probably a better migration path can happen over time. may be we can raname
existing autotools.bbclass to autotoolsold and have autotools.bbclass
default to S != B
that way the recipes which break can inherit autotoolsold and can have quick fix
then we can slowly remove inheriting autotoolsold and finally remove
the class itself.

>
> Have we got the willpower to fix a)? is b) an option? Other ideas?
>
> One way or another I think we should try and switch things somehow...
>
> Cheers,
>
> Richard
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: RFC: Separate build dir for autotools

[Burton, Ross]

On 25 February 2014 05:46, Khem Raj <raj.khem@gmail.com> wrote:
>> 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.
>
> probably a better migration path can happen over time. may be we can raname
> existing autotools.bbclass to autotoolsold and have autotools.bbclass
> default to S != B
> that way the recipes which break can inherit autotoolsold and can have quick fix
> then we can slowly remove inheriting autotoolsold and finally remove
> the class itself.

I really don't see the point of this churn.  If autotools defaults to
B!=S then the recipe is going to need changing anyway, and adding
B=${S} in the recipe is far lower impact than having a fork of
autotools.bbclass that has one change and would need to remain (and be
maintained) for several release cycles.

Ross

Re: RFC: Separate build dir for autotools

[Khem Raj]

On Tue, Feb 25, 2014 at 1:52 AM, Burton, Ross <ross.burton@intel.com> wrote:
> On 25 February 2014 05:46, Khem Raj <raj.khem@gmail.com> wrote:
>>> 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.
>>
>> probably a better migration path can happen over time. may be we can raname
>> existing autotools.bbclass to autotoolsold and have autotools.bbclass
>> default to S != B
>> that way the recipes which break can inherit autotoolsold and can have quick fix
>> then we can slowly remove inheriting autotoolsold and finally remove
>> the class itself.
>
> I really don't see the point of this churn.  If autotools defaults to
> B!=S then the recipe is going to need changing anyway, and adding
> B=${S} in the recipe is far lower impact than having a fork of
> autotools.bbclass

OK yes.

that has one change and would need to remain (and be
> maintained) for several release cycles.
>
> Ross

Re: RFC: Separate build dir for autotools

[Nicolas Dechesne]

On Mon, Feb 24, 2014 at 5:09 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>
>> That list is opt-in and mainly covers oe-core, so this gets tested
>> every time the YP autobuilder does a world build.  We need a meta-oe
>> world build where autotools.bbclass sets B="${WORKDIR}/build": it's
>> literally just this one-line patch.
>
> But doesn't cover oe-core built with different combinations for
> PACKAGECONFIGs, .bbappends etc, so including this file in
> defaultsetup.conf can still reveal few issues in oe-core recipes.

right. I have recently (on dora) noticed that mesa build is broken
when using separate build dir, i have the following extra config:

PACKAGECONFIG_append = " gallium gallium-egl gallium-gbm gallium-llvm"

since gallium-egl needs the egl.h files generated during mesa build.
the generated files stay in $B while gallium-egl is looking for them
in $S (or sysroot)

Re: RFC: Separate build dir for autotools

[Burton, Ross]

On 25 February 2014 17:36, Nicolas Dechesne <nicolas.dechesne@linaro.org> wrote:
> right. I have recently (on dora) noticed that mesa build is broken
> when using separate build dir, i have the following extra config:
>
> PACKAGECONFIG_append = " gallium gallium-egl gallium-gbm gallium-llvm"
>
> since gallium-egl needs the egl.h files generated during mesa build.
> the generated files stay in $B while gallium-egl is looking for them
> in $S (or sysroot)

Pretty sure I fixed that:  oe-core fbc7092f0ae07538d4363679b1597ba4e556d1a8

It looks like that's in Dora so we've possibly regressed again, can
you file a bug (CCing me) with the build log?

Ross

Re: RFC: Separate build dir for autotools

[Nicolas Dechesne]

On Tue, Feb 25, 2014 at 7:43 PM, Burton, Ross <ross.burton@intel.com> wrote:
> On 25 February 2014 17:36, Nicolas Dechesne <nicolas.dechesne@linaro.org> wrote:
>> right. I have recently (on dora) noticed that mesa build is broken
>> when using separate build dir, i have the following extra config:
>>
>> PACKAGECONFIG_append = " gallium gallium-egl gallium-gbm gallium-llvm"
>>
>> since gallium-egl needs the egl.h files generated during mesa build.
>> the generated files stay in $B while gallium-egl is looking for them
>> in $S (or sysroot)
>
> Pretty sure I fixed that:  oe-core fbc7092f0ae07538d4363679b1597ba4e556d1a8
>
> It looks like that's in Dora so we've possibly regressed again, can
> you file a bug (CCing me) with the build log?

oops. you're right. it's fixed in both dora and master. in fact i got
hit by that on dylan... but they i switched to dora anyways... so this
one is fine.

Re: RFC: Separate build dir for autotools

[Nicolas Dechesne]

Ross,

On Tue, Feb 25, 2014 at 11:10 PM, Nicolas Dechesne
<nicolas.dechesne@linaro.org> wrote:
> oops. you're right. it's fixed in both dora and master. in fact i got
> hit by that on dylan... but they i switched to dora anyways... so this
> one is fine.

I guess i spoke too quickly... i just retried a dora and master after
cleansstate on mesa, and master seems to build fine, but dora failed
to build. see

https://bugzilla.yoctoproject.org/show_bug.cgi?id=5882

Re: RFC: Separate build dir for autotools

[Martin Jansa]

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

On Mon, Feb 24, 2014 at 04:27:04PM +0000, Richard Purdie wrote:
> On Mon, 2014-02-24 at 17:09 +0100, Martin Jansa wrote:
> > On Mon, Feb 24, 2014 at 03:41:11PM +0000, Burton, Ross wrote:
> > > On 24 February 2014 15:27, Martin Jansa <martin.jansa@gmail.com> wrote:
> > > > 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?
> > > 
> > > That list is opt-in and mainly covers oe-core, so this gets tested
> > > every time the YP autobuilder does a world build.  We need a meta-oe
> > > world build where autotools.bbclass sets B="${WORKDIR}/build": it's
> > > literally just this one-line patch.
> > 
> > But doesn't cover oe-core built with different combinations for
> > PACKAGECONFIGs, .bbappends etc, so including this file in
> > defaultsetup.conf can still reveal few issues in oe-core recipes.
> 
> Patch out for testing, I'll merge it if nobody objects...

I've added it to my world builds as soon as you sent it.. but only 1
architecture was finished since then :/

Is it supposed to work correctly in incremental builds? Today I've seen
couple of components failing in do_configure and building fine after
manual clean, interesting part of log is that autotools.bbclass was
actually trying to clean them:

Previously configured separate build directory detected, cleaning
/OE/../oprofileui-server/0.0+gitAUTOINC+f168b8bfdc-r0/build
..
checking whether make supports nested variables... yes
configure: error: source directory already configured; run "make distclean" there first
Configure failed. The contents of all config.log files follows to aid debugging
/OE/../oprofileui-server/0.0+gitAUTOINC+f168b8bfdc-r0/git/config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by oprofileui configure 0.2.0, which was

The working version also has:
configure.ac:5: warning: AM_INIT_AUTOMAKE: two- and three-arguments forms are deprecated.  For more info, see:
configure.ac:5: http://www.gnu.org/software/automake/manual/automake.html#Modernize-AM_005fINIT_005fAUTOMAKE-invocation
configure.ac:8: installing './compile'
configure.ac:5: installing './install-sh'
configure.ac:5: installing './missing'
protocol/Makefile.am: installing './depcomp'

I've seen similar behavior in 3 other components.

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

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

Re: RFC: Separate build dir for autotools

[Burton, Ross]

On 26 February 2014 19:11, Martin Jansa <martin.jansa@gmail.com> wrote:
> Is it supposed to work correctly in incremental builds? Today I've seen
> couple of components failing in do_configure and building fine after
> manual clean, interesting part of log is that autotools.bbclass was
> actually trying to clean them:

autotools will clean away the stale build/ directory but it won't
clean ${S} sufficiently to convince configure that it can re-execute
with a different build directory.  autoconf is a bit weird here, so
sadly this means enabling B!=S for a recipe means doing a clean on
that recipe.

Unless, of course, you work out where configure is looking to bail on
this test, and if we can safely remove it on rebuilds.

Ross

Re: RFC: Separate build dir for autotools

[Phil Blundell]

On Wed, 2014-02-26 at 19:54 +0000, Burton, Ross wrote:
> Unless, of course, you work out where configure is looking to bail on
> this test, and if we can safely remove it on rebuilds.

I don't think there's any safe way of defeating that configure check
other than to properly clean ${S}.  You could add something like:

if [ -f ${S}/config.status ]; then
  ( cd ${S} ; make distclean || true )
fi

to autotools.bbclass, which would probably take care of most of the
simple cases.

If you just remove config.status (and maybe config.h) then that'd
probably be enough to fool configure, but then you'd be running the risk
that the vpaths would pick up stale copies of generated files from ${S}
rather than rebuilding them in ${B}.

p.