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 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.