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`
next prev parent 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