All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: "Björn Stenberg" <bjst@enea.com>
Cc: bitbake-devel@lists.openembedded.org
Subject: Re: [PATCH 1/2] bitbake: ensure -f causes dependent tasks to be re-run
Date: Wed, 20 Jun 2012 09:38:40 +0100	[thread overview]
Message-ID: <1340181520.1640.26.camel@ted> (raw)
In-Reply-To: <20120620075504.GB22538@giant>

On Wed, 2012-06-20 at 09:55 +0200, Björn Stenberg wrote:
> Paul Eggleton wrote:
> > So my assumption is -f is most often used for the purpose of manually
> > forcing a recompile after you have made modifications to the already
> > extracted source code under the workdir.
> 
> I agree with that.
> 
> My concern is based on the fact that people (including myself) don't
> fully know all the details of how bitbake works, and tend to make
> assumptions based on other build systems they know, such as simple
> Makefiles.
> 
> I think the fact that bitbake sometime works differently means we
> should be extra careful about not playing into devlelopers'
> assumptions. The bitbake option --force sounds rather similar to
> make's --always-make, especially when it is described as: "force run
> of specified cmd, regardless of stamp status". While a tangent, the
> --force parameter in standard unix utils like cp, mv, rm also matter.
> 
> If we were to call it something different instead, like -t/--taint,
> this would avoid some assumptions about its behaviour and make it more
> clear that the output will be different even if the input is the same.
> 
> Sure, it's not a major issue. But I'm fairly confident that if we keep
> the option name but change its behaviour, I am going to have to
> explain more than once to developers not following this list or the
> commit logs why -f does not do what they think (even though one can
> argue it never did). I'd rather they discover up front that -f is
> deprecated and that they should look up a new option instead.

We should be clear, its not a change in behaviour, its a bugfix for a
variety of nasty problems related to sstate. sstate needs to behave as
people would expect under a variety of circumstances and this change
only changes the interaction between sstate and the stamp files. This is
an area that is relatively new, we've found a nasty issue where sstate
files can become "corrupted" and we need to avoid that as it threatens
the integrity of the project.

I don't think renaming the option is a particularly good idea, that will
upset many user's fingers and mean we have to scrub the documents and in
itself will cause a ton of questions that need to be answered.

I would agree that the bitbake help text should be enhanced to make it
clear what this option does though. I do also think we need to raise
awareness of the change (which is why it was mentioned in yesterday's
meeting).

I appreciate we probably will get this question from time to time. We
(Yocto) are working on adding some kind of question/answer system (stack
overflow style) to the website btw, and this would make a good question
and answer on there! That would give us all a lightweight way to at
least answer the question.

Cheers,

Richard






  reply	other threads:[~2012-06-20  8:49 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-18 15:45 [PATCH 0/2] Signature-based rebuild improvements Paul Eggleton
2012-06-18 15:45 ` [PATCH 1/2] bitbake: ensure -f causes dependent tasks to be re-run Paul Eggleton
2012-06-19 19:35   ` Björn Stenberg
2012-06-19 23:50     ` Paul Eggleton
2012-06-20  7:45       ` Björn Stenberg
2012-06-20  7:55       ` Björn Stenberg
2012-06-20  8:38         ` Richard Purdie [this message]
2012-06-20  8:40         ` Paul Eggleton
2012-06-21 11:25           ` Björn Stenberg
2012-06-21 12:10             ` Paul Eggleton
2012-06-21 12:26               ` Björn Stenberg
2012-06-21 13:25                 ` Paul Eggleton
2012-06-21 13:41                 ` Björn Stenberg
2012-06-21 13:52                   ` Paul Eggleton
2012-06-21 14:44                 ` Richard Purdie
2012-06-18 15:45 ` [PATCH 2/2] bitbake: add -C option to invalidate a task and rebuild the target Paul Eggleton
2012-06-19 11:43 ` [PATCH 0/2] Signature-based rebuild improvements Jason Wessel
2012-06-19 13:02   ` Paul Eggleton
2012-06-19 17:20   ` Gopi - College
2012-06-20 18:11     ` p2020rdb - httpd+php Gopi - College
2012-06-20  8:42   ` [PATCH 0/2] Signature-based rebuild improvements Richard Purdie

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=1340181520.1640.26.camel@ted \
    --to=richard.purdie@linuxfoundation.org \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=bjst@enea.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.