From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: "Burton, Ross" <ross.burton@intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH] autotools.bbclass: Add functionality to force a distclean when reconfiguring
Date: Fri, 07 Sep 2012 18:09:32 +0100 [thread overview]
Message-ID: <1347037772.8619.24.camel@ted> (raw)
In-Reply-To: <CAJTo0LYnG1BdZ=UkKPWju7UwBZWjEJhQ_svmO4bVwaSL1ZGGkA@mail.gmail.com>
On Fri, 2012-09-07 at 17:42 +0100, Burton, Ross wrote:
> On 7 September 2012 17:32, Mark Hatle <mark.hatle@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 nice to test the things that
> > don't use the autotools.bbclass..)
>
> Yeah, I expect we'll discover some cases when upstream just don't
> expect a distclean. By generally taking from git and re-running the
> entire autotools we *should* be okay, but...
Further testing suggests we either going to need a whitelist or a
blacklist for this :/
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.
FWIW, libgpg-error fails with checksum issues (checksumming a generated
file?!) and libtool has issues about cleaning directories that have
makefiles that were never generated...
Cheers,
Richard
next prev parent reply other threads:[~2012-09-07 17:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-07 16:05 [PATCH] autotools.bbclass: Add functionality to force a distclean when reconfiguring Richard Purdie
2012-09-07 16:32 ` Mark Hatle
2012-09-07 16:37 ` Richard Purdie
2012-09-07 16:42 ` Burton, Ross
2012-09-07 17:09 ` Richard Purdie [this message]
2012-09-07 17:15 ` Phil Blundell
2012-09-08 8:05 ` Khem Raj
2012-09-08 13:30 ` Mark Hatle
2012-09-08 15:36 ` Colin Walters
2012-09-08 15:44 ` Colin Walters
2012-09-08 15:49 ` Mark Hatle
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=1347037772.8619.24.camel@ted \
--to=richard.purdie@linuxfoundation.org \
--cc=openembedded-core@lists.openembedded.org \
--cc=ross.burton@intel.com \
/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 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.