On (07/09/12 18:15), Phil Blundell wrote:
On Fri, 2012-09-07 at 18:09 +0100, Richard Purdie wrote:
The key places people get bitten are eglibc and gcc so those should be
straight forward to test, the question is how widely to deploy this
initially. I think the mechanism is good, its now
On 9/8/12 3:05 AM, Khem Raj wrote:
On (07/09/12 18:15), Phil Blundell wrote:
On Fri, 2012-09-07 at 18:09 +0100, Richard Purdie wrote:
The key places people get bitten are eglibc and gcc so those should be
straight forward to test, the question is how widely to deploy this
initially. I think
On Fri, 2012-09-07 at 17:05 +0100, Richard Purdie wrote:
Unfortunately whilst reruning configure and make against a project will mostly
work there are situations where it does not correctly do the right thing.
In particular, eglibc and gcc will fail out with errors where settings
do not
On Sat, 2012-09-08 at 08:30 -0500, Mark Hatle wrote:
In principal I agree completely, however in practice at least 20-30% of the
packages I try won't deal w/ the B/S separation properly.
So what I did in my most recent build system[1] is:
1) Default to srcdir != builddir
2) Tag modules which
On 9/8/12 10:44 AM, Colin Walters wrote:
On Fri, 2012-09-07 at 17:05 +0100, Richard Purdie wrote:
Unfortunately whilst reruning configure and make against a project will mostly
work there are situations where it does not correctly do the right thing.
In particular, eglibc and gcc will fail out
Unfortunately whilst reruning configure and make against a project will mostly
work there are situations where it does not correctly do the right thing.
In particular, eglibc and gcc will fail out with errors where settings
do not match a previously built configuration. It could be argued they
I'm curious, is there any [easy] way we can force a rerun of configure as a test
pass over the system?
I'd like a way to verify that both this patch works as expected, and future
recipes work as expected. (It would also be nice to test the things that don't
use the autotools.bbclass..)
On Fri, 2012-09-07 at 11:32 -0500, Mark Hatle wrote:
I'm curious, is there any [easy] way we can force a rerun of configure as a
test
pass over the system?
rm tmp/stamps/*/*do_configure*
along with a rename of the sstate cache so it doesn't get used.
I'd like a way to verify that both
On 7 September 2012 17:32, Mark Hatle mark.ha...@windriver.com wrote:
I'm curious, is there any [easy] way we can force a rerun of configure as a
test pass over the system?
I'd like a way to verify that both this patch works as expected, and future
recipes work as expected. (It would also be
On Fri, 2012-09-07 at 17:42 +0100, Burton, Ross wrote:
On 7 September 2012 17:32, Mark Hatle mark.ha...@windriver.com wrote:
I'm curious, is there any [easy] way we can force a rerun of configure as a
test pass over the system?
I'd like a way to verify that both this patch works as
On Fri, 2012-09-07 at 18:09 +0100, Richard Purdie wrote:
The key places people get bitten are eglibc and gcc so those should be
straight forward to test, the question is how widely to deploy this
initially. I think the mechanism is good, its now just a question of the
implementation detail.
11 matches
Mail list logo
