Openembedded Core Discussions
 help / color / mirror / Atom feed
From: Andreas Oberritter <obi@opendreambox.org>
To: Paul Eggleton <paul.eggleton@linux.intel.com>
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 1/6] scripts/bitbake: ensure user is in build directory
Date: Fri, 16 Mar 2012 01:20:44 +0100	[thread overview]
Message-ID: <4F62875C.60303@opendreambox.org> (raw)
In-Reply-To: <665936693.QMobc8r8oH@helios>

On 16.03.2012 00:09, Paul Eggleton wrote:
> On Thursday 15 March 2012 01:30:31 Andreas Oberritter wrote:
>> On 14.03.2012 01:36, Paul Eggleton wrote:
>>> If the user is in any directory other than $BUILDDIR when the bitbake
>>> wrapper script is run, then show an error an exit.
>>
>> this patch broke my setup.
> 
> Ah, sorry about that.
>  
>> My $BUILDDIR points to tmp, so that pseudo doesn't get rebuilt for every
>> machine. I have a shared tmp for many machines.
> 
> So a couple of things:
> 
> 1) Unless I'm missing something you can share the same TMPDIR between multiple 
> build directories to get the same result.
>  
> 2) pseudo is a native package. It shouldn't be rebuilt when changing MACHINE. 
> In fact I just verified by creating a different build directory with only 
> MACHINE changed in the config, it is not rebuilt.

Sorry, I messed up some details. In fact, pseudo-native doesn't get
rebuilt, but bitbake pseudo-native still gets executed for every
machine, unless $BUILDDIR/pseudodone is present and contains
PSEUDOBINDIR. This just wastes time and confuses users who receive a
message saying "Pseudo is not present but is required, building this
first before the main build".

>> BUILDDIR doesn't seem to have any other use than pointing to the
>> 'pseudodone' file. I don't understand why it's required to run bitbake
>> from there.
> 
> Well, it's required that bitbake is run from the build directory and when you 
> use the setup script as intended that's where BUILDDIR points to. I hadn't 
> anticipated that anyone would be changing BUILDDIR to point to anything other 
> than the build dir, however I don't really think it's a good idea to support 
> that.

That's because BUILDDIR has no meaning outside oe-core's setup scripts.
In scripts/bitbake, BUILDDIR would better be called PSEUDODONEDIR or
similar, because that's what the variable really means in this context
[1]. If I had a choice to override a more suitably named variable I
certainly would do that. ;-)

In order to verify that scripts/bitbake is called from the build
directory, you could as well just check whether $PWD/conf/local.conf exists.

I'm not using oe-core's scripts, because they make assumptions about the
directory layout that don't fit my project's needs. I think they are
overly complex and they display texts that seem to suit yocto's needs
but at least not mine.

Regards,
Andreas

[1]
$ grep BUILDDIR scripts/bitbake
if [ $needpseudo = "1" ] && [ -e "$BUILDDIR/pseudodone" ]; then
    PSEUDOBINDIR=`cat $BUILDDIR/pseudodone`
    echo $PSEUDOBINDIR > $BUILDDIR/pseudodone
    PSEUDOBINDIR=`cat $BUILDDIR/pseudodone`



  reply	other threads:[~2012-03-16  0:29 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-14  0:36 [PATCH 0/6] Misc build failure fixes Paul Eggleton
2012-03-14  0:36 ` [PATCH 1/6] scripts/bitbake: ensure user is in build directory Paul Eggleton
2012-03-14 14:52   ` Darren Hart
2012-03-14 15:09     ` Paul Eggleton
2012-03-14 15:19       ` Darren Hart
2012-03-15  0:30   ` Andreas Oberritter
2012-03-15 23:09     ` Paul Eggleton
2012-03-16  0:20       ` Andreas Oberritter [this message]
2012-03-16 10:56         ` Paul Eggleton
2012-03-16 11:55           ` VIJAY KUMAR
2012-03-16 12:19             ` Paul Eggleton
2012-03-18 15:07           ` Andreas Oberritter
2012-04-02 20:00   ` Khem Raj
2012-04-02 20:12     ` Paul Eggleton
2012-04-02 20:32       ` Chris Larson
2012-04-02 20:56         ` Paul Eggleton
2012-03-14  0:36 ` [PATCH 2/6] pulseaudio: add X library dependencies Paul Eggleton
2012-03-14  0:36 ` [PATCH 3/6] gst-plugins-bad: disable directfb in configure Paul Eggleton
2012-03-14  0:36 ` [PATCH 4/6] mx: add dependencies Paul Eggleton
2012-03-14  0:36 ` [PATCH 5/6] ncurses: fix build when ENABLE_WIDEC is not set Paul Eggleton
2012-03-14 14:52   ` Darren Hart
2012-03-14  0:36 ` [PATCH 6/6] linux-yocto-tiny: add dependency on xz-native Paul Eggleton
2012-03-14  8:21   ` Koen Kooi
2012-03-14  8:32     ` Paul Eggleton
2012-03-14 12:29       ` Bruce Ashfield
2012-03-14 12:39         ` Paul Eggleton
2012-03-14 12:59           ` Bruce Ashfield
2012-03-14 13:03             ` Paul Eggleton
2012-03-14 13:12               ` Bruce Ashfield
2012-03-14 14:55                 ` Darren Hart
2012-03-14 13:18 ` [PATCH 0/6] Misc build failure fixes 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=4F62875C.60303@opendreambox.org \
    --to=obi@opendreambox.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=paul.eggleton@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox