* RFC: Separate build dir for autotools @ 2014-02-24 14:58 Richard Purdie 2014-02-24 15:06 ` Otavio Salvador ` (2 more replies) 0 siblings, 3 replies; 16+ messages in thread From: Richard Purdie @ 2014-02-24 14:58 UTC (permalink / raw) To: openembedded-core 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFC: Separate build dir for autotools 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 2014-02-25 5:46 ` Khem Raj 2 siblings, 0 replies; 16+ messages in thread From: Otavio Salvador @ 2014-02-24 15:06 UTC (permalink / raw) To: Richard Purdie; +Cc: openembedded-core 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFC: Separate build dir for autotools 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 2014-02-24 15:41 ` Burton, Ross 2014-02-25 5:46 ` Khem Raj 2 siblings, 1 reply; 16+ messages in thread From: Martin Jansa @ 2014-02-24 15:27 UTC (permalink / raw) To: Richard Purdie; +Cc: openembedded-core [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFC: Separate build dir for autotools 2014-02-24 15:27 ` Martin Jansa @ 2014-02-24 15:41 ` Burton, Ross 2014-02-24 16:09 ` Martin Jansa 0 siblings, 1 reply; 16+ messages in thread From: Burton, Ross @ 2014-02-24 15:41 UTC (permalink / raw) To: Martin Jansa; +Cc: openembedded-core 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFC: Separate build dir for autotools 2014-02-24 15:41 ` Burton, Ross @ 2014-02-24 16:09 ` Martin Jansa 2014-02-24 16:27 ` Richard Purdie 2014-02-25 17:36 ` Nicolas Dechesne 0 siblings, 2 replies; 16+ messages in thread From: Martin Jansa @ 2014-02-24 16:09 UTC (permalink / raw) To: Burton, Ross; +Cc: openembedded-core [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFC: Separate build dir for autotools 2014-02-24 16:09 ` Martin Jansa @ 2014-02-24 16:27 ` Richard Purdie 2014-02-26 19:11 ` Martin Jansa 2014-02-25 17:36 ` Nicolas Dechesne 1 sibling, 1 reply; 16+ messages in thread From: Richard Purdie @ 2014-02-24 16:27 UTC (permalink / raw) To: Martin Jansa; +Cc: openembedded-core 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFC: Separate build dir for autotools 2014-02-24 16:27 ` Richard Purdie @ 2014-02-26 19:11 ` Martin Jansa 2014-02-26 19:54 ` Burton, Ross 0 siblings, 1 reply; 16+ messages in thread From: Martin Jansa @ 2014-02-26 19:11 UTC (permalink / raw) To: Richard Purdie; +Cc: openembedded-core [-- 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 --] ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFC: Separate build dir for autotools 2014-02-26 19:11 ` Martin Jansa @ 2014-02-26 19:54 ` Burton, Ross 2014-02-26 20:20 ` Phil Blundell 0 siblings, 1 reply; 16+ messages in thread From: Burton, Ross @ 2014-02-26 19:54 UTC (permalink / raw) To: Martin Jansa; +Cc: openembedded-core 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFC: Separate build dir for autotools 2014-02-26 19:54 ` Burton, Ross @ 2014-02-26 20:20 ` Phil Blundell 0 siblings, 0 replies; 16+ messages in thread From: Phil Blundell @ 2014-02-26 20:20 UTC (permalink / raw) To: Burton, Ross; +Cc: openembedded-core 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFC: Separate build dir for autotools 2014-02-24 16:09 ` Martin Jansa 2014-02-24 16:27 ` Richard Purdie @ 2014-02-25 17:36 ` Nicolas Dechesne 2014-02-25 18:43 ` Burton, Ross 1 sibling, 1 reply; 16+ messages in thread From: Nicolas Dechesne @ 2014-02-25 17:36 UTC (permalink / raw) To: Martin Jansa; +Cc: openembedded-core 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) ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFC: Separate build dir for autotools 2014-02-25 17:36 ` Nicolas Dechesne @ 2014-02-25 18:43 ` Burton, Ross 2014-02-25 22:10 ` Nicolas Dechesne 0 siblings, 1 reply; 16+ messages in thread From: Burton, Ross @ 2014-02-25 18:43 UTC (permalink / raw) To: Nicolas Dechesne; +Cc: openembedded-core 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFC: Separate build dir for autotools 2014-02-25 18:43 ` Burton, Ross @ 2014-02-25 22:10 ` Nicolas Dechesne 2014-02-26 10:58 ` Nicolas Dechesne 0 siblings, 1 reply; 16+ messages in thread From: Nicolas Dechesne @ 2014-02-25 22:10 UTC (permalink / raw) To: Burton, Ross; +Cc: openembedded-core 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFC: Separate build dir for autotools 2014-02-25 22:10 ` Nicolas Dechesne @ 2014-02-26 10:58 ` Nicolas Dechesne 0 siblings, 0 replies; 16+ messages in thread From: Nicolas Dechesne @ 2014-02-26 10:58 UTC (permalink / raw) To: Burton, Ross; +Cc: openembedded-core 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFC: Separate build dir for autotools 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 @ 2014-02-25 5:46 ` Khem Raj 2014-02-25 9:52 ` Burton, Ross 2 siblings, 1 reply; 16+ messages in thread From: Khem Raj @ 2014-02-25 5:46 UTC (permalink / raw) To: Richard Purdie; +Cc: openembedded-core 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFC: Separate build dir for autotools 2014-02-25 5:46 ` Khem Raj @ 2014-02-25 9:52 ` Burton, Ross 2014-02-25 16:32 ` Khem Raj 0 siblings, 1 reply; 16+ messages in thread From: Burton, Ross @ 2014-02-25 9:52 UTC (permalink / raw) To: Khem Raj; +Cc: openembedded-core 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: RFC: Separate build dir for autotools 2014-02-25 9:52 ` Burton, Ross @ 2014-02-25 16:32 ` Khem Raj 0 siblings, 0 replies; 16+ messages in thread From: Khem Raj @ 2014-02-25 16:32 UTC (permalink / raw) To: Burton, Ross; +Cc: openembedded-core 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2014-02-26 20:20 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 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
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.