Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Phil Blundell <philb@gnu.org>
Cc: oe-core <openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH] autotools: Attempt to clean build directory when rerunning configure
Date: Tue, 30 Oct 2012 08:10:42 +0000	[thread overview]
Message-ID: <1351584642.2828.58.camel@ted> (raw)
In-Reply-To: <1351534455.13864.25.camel@phil-desktop>

On Mon, 2012-10-29 at 18:14 +0000, Phil Blundell wrote:
> Existing logic in autotools_preconfigure() will clean the build directory
> before rerunning configure in the case where ${S} != ${B}.  It is, however,
> desirable to make at least some attempt to clean the build artifacts for
> in-tree builds since many packages lack the appropriate dependency rules
> to force a recompile if (for example) CFLAGS has changed.  Making distclean
> would be better but is not practical because many packages don't support it
> properly.  Even "make clean" is not universally available, so we ignore any
> failure from that command and just carry on regardless.
> 
> Signed-off-by: Phil Blundell <philb@gnu.org>
> ---
>  meta/classes/autotools.bbclass |   13 +++++++++----
>  1 file changed, 9 insertions(+), 4 deletions(-)

How extensively has this been tested? I have a suspicion that we might
run into a number of issues doing this throughout the tree :(

I'm wondering how many recipes will suffer from issues with "make clean"
verses how many recipes would struggle if we defaulted ${B} != ${S}?

Cheers,

Richard


> diff --git a/meta/classes/autotools.bbclass b/meta/classes/autotools.bbclass
> index b97d74b..6539df9 100644
> --- a/meta/classes/autotools.bbclass
> +++ b/meta/classes/autotools.bbclass
> @@ -93,10 +93,15 @@ CONFIGURESTAMPFILE = "${WORKDIR}/configure.sstate"
>  
>  autotools_preconfigure() {
>  	if [ -n "${CONFIGURESTAMPFILE}" -a -e "${CONFIGURESTAMPFILE}" ]; then
> -		if [ "`cat ${CONFIGURESTAMPFILE}`" != "${BB_TASKHASH}" -a "${S}" != "${B}" ]; then
> -			echo "Previously configured separate build directory detected, cleaning ${B}"
> -			rm -rf ${B}
> -			mkdir ${B}
> +		if [ "`cat ${CONFIGURESTAMPFILE}`" != "${BB_TASKHASH}" ]; then
> +			if [ "${S}" != "${B}" ]; then
> +				echo "Previously configured separate build directory detected, cleaning ${B}"
> +				rm -rf ${B}
> +				mkdir ${B}
> +			else
> +				echo "Previously configured source directory detected, cleaning ${S}"
> +				( oe_runmake clean ) || true
> +			fi
>  		fi
>  	fi
>  }





  reply	other threads:[~2012-10-30  8:24 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-29 18:14 [PATCH] autotools: Attempt to clean build directory when rerunning configure Phil Blundell
2012-10-30  8:10 ` Richard Purdie [this message]
2012-10-30 12:19   ` Phil Blundell

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=1351584642.2828.58.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=philb@gnu.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox