Re: [OE-core] RFC: Separate build dir for autotools
Ross, On Tue, Feb 25, 2014 at 11:10 PM, Nicolas Dechesne nicolas.deche...@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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Separate build dir for autotools
On Mon, Feb 24, 2014 at 04:27:04PM +, Richard Purdie wrote:
On Mon, 2014-02-24 at 17:09 +0100, Martin Jansa wrote:
On Mon, Feb 24, 2014 at 03:41:11PM +, Burton, Ross wrote:
On 24 February 2014 15:27, Martin Jansa martin.ja...@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.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Separate build dir for autotools
On 26 February 2014 19:11, Martin Jansa martin.ja...@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
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Separate build dir for autotools
On Wed, 2014-02-26 at 19:54 +, 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.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Separate build dir for autotools
On 25 February 2014 05:46, Khem Raj raj.k...@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
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Separate build dir for autotools
On Tue, Feb 25, 2014 at 1:52 AM, Burton, Ross ross.bur...@intel.com wrote:
On 25 February 2014 05:46, Khem Raj raj.k...@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
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Separate build dir for autotools
On Mon, Feb 24, 2014 at 5:09 PM, Martin Jansa martin.ja...@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)
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Separate build dir for autotools
On 25 February 2014 17:36, Nicolas Dechesne nicolas.deche...@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 ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Separate build dir for autotools
On Tue, Feb 25, 2014 at 7:43 PM, Burton, Ross ross.bur...@intel.com wrote: On 25 February 2014 17:36, Nicolas Dechesne nicolas.deche...@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. ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Separate build dir for autotools
Hello Richard,
On Mon, Feb 24, 2014 at 11:58 AM, Richard Purdie
richard.pur...@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.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Separate build dir for autotools
On 24 February 2014 15:27, Martin Jansa martin.ja...@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
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Separate build dir for autotools
On Mon, Feb 24, 2014 at 03:41:11PM +, Burton, Ross wrote:
On 24 February 2014 15:27, Martin Jansa martin.ja...@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.ja...@gmail.com
signature.asc
Description: Digital signature
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Separate build dir for autotools
On Mon, 2014-02-24 at 17:09 +0100, Martin Jansa wrote:
On Mon, Feb 24, 2014 at 03:41:11PM +, Burton, Ross wrote:
On 24 February 2014 15:27, Martin Jansa martin.ja...@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
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] RFC: Separate build dir for autotools
On Mon, Feb 24, 2014 at 6:58 AM, Richard Purdie
richard.pur...@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
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
