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: Sun, 18 Mar 2012 16:07:15 +0100	[thread overview]
Message-ID: <4F65FA23.7050309@opendreambox.org> (raw)
In-Reply-To: <1481997.vT15FBqihJ@helios>

On 16.03.2012 11:56, Paul Eggleton wrote:
> On Friday 16 March 2012 01:20:44 Andreas Oberritter wrote:
>> 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".
> 
> It takes a small amount of time just once. However if this is really an issue 
> perhaps we could address it directly rather than hacking around it?
> 
>>>> 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
> 
> The naming is such that it should point to the build directory because that's 
> where pseudodone is meant to be written. I think when it was introduced there 
> was an idea that it might be useful in other contexts, thus the naming.

What is the reason for storing 'pseudodone' inside BUILDDIR? Wouldn't it
better be stored inside TMPDIR by default? Isn't there any way to get
rid of pseudodone completely?

>> 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.
> 
> Unfortunately it's not that simple. bitbake.conf pulls in local.conf using 
> "include" and not "require", thus it doesn't actually have to exist anywhere.

In fact it is that simple, because If local.conf doesn't exist,
oe-setup-builddir creates it.

>> 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
> 
> Could you perhaps elaborate on what needs those scripts are not fulfilling?

1.) OE-core is not my top-level directory. It's included as a git
submodule. it must not contain any data not fetched from the OE-core
repository (i.e. no bitbake tree, no build dirs).

2.) Switching between build directories must not involve changing the
environment.

>> and they display texts that seem to suit yocto's needs but at least not
>> mine.
> 
> We print these messages so that people know what to do and where to find 
> further information. I don't think that's unreasonable. However if you have 
> suggestions on how we might improve those messages or allow them to be 
> customised if necessary, we could look at changing them.

I'd like to display none of those messages to my users. We have our own
help texts that are specific to our distribution and configuration.

Our setup script is based on GNU make and uses make's dependency
tracking. It creates local.conf on its own. I don't want any other
script to do that.

I really don't want to be forced to use those OE-core scripts, if a
two-line script is sufficient to fulfil my needs. This two-line script
just sets up the path to bitbake and sets the location of 'pseudodone'
(which already sucks - the path to bitbake should be sufficient alone).

Regards,
Andreas



  parent reply	other threads:[~2012-03-18 15:16 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
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 [this message]
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=4F65FA23.7050309@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