From: Rich Pixley <rich.pixley@palm.com>
To: Saul Wold <sgw@linux.intel.com>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: local.conf & bblayers.conf changes...
Date: Tue, 03 Jul 2012 10:19:46 -0700 [thread overview]
Message-ID: <4FF329B2.1040101@palm.com> (raw)
In-Reply-To: <4FF32550.6060606@linux.intel.com>
On 7/3/12 10:01 , Saul Wold wrote:
> On 07/03/2012 09:42 AM, Rich Pixley wrote:
>> Where can I find a description of the recent changes and what I need to
>> do to bring my files back up to current?
>>
>> What were the incompatible changes?
>>
> For bblayers.conf, we bumped the version becase we moved the BBPATH
> initial setting into the bblayers.conf to ensure we dont accidently
> pickup things in . because of the way a :: was being parsed. See
> this commit
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=5e3a61b40b7b697d83b41e7e247cd1f94eb7673c
>
> Not sure what you mean about local.conf, since I am not sure of your
> starting point.
Ok, so I *liked* having BBPATH be relative. The alternative, using
absolute pathnames, means that you have to bolt absolute path names into
all of your binaries, all of your debug symbols, and all of your build
configurations. This means that your binary sizes are greater, that
debug symbols are significantly greater and more difficult to configure
properly in your debuger, and that working directories cannot be moved
around or renamed without needing to manually force full rebuilds. It
also means that some forms of file system checkpointing can't be used
since you can't rely on the build to be in the same place on the file
system every build.
I'll try to roll with the current plan, though.
In the current arrangement, I'm getting confusing messages about not
setting MACHINE, even though MACHINE is set in my local.conf. I'm
guessing that means that the pathing is busted and it's not finding my
local.conf. How is the initial configuration file found? And which
configuration file is initial? Is that "./conf/bblayers.conf"? And if
so, does this mean that I need to put my other directory assignments
like TOPDIR and TMPDIR in bblayers.conf as well? And if so, then what's
the logical distinction between bblayers.conf and local.conf at this
point if build policy needs to go into bblayers.conf?
--rich
next prev parent reply other threads:[~2012-07-03 17:30 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-03 16:42 local.conf & bblayers.conf changes Rich Pixley
2012-07-03 17:01 ` Saul Wold
2012-07-03 17:19 ` Rich Pixley [this message]
2012-07-03 17:35 ` Mark Hatle
2012-07-03 17:47 ` Martin Jansa
2012-07-03 17:51 ` Mark Hatle
2012-07-03 18:00 ` Martin Jansa
2012-07-03 19:20 ` Paul Eggleton
2012-07-03 17:22 ` Martin Jansa
2012-07-03 17:40 ` Jack Mitchell
2012-07-03 19:22 ` Paul Eggleton
2012-07-04 8:29 ` Jack Mitchell
2012-07-04 8:32 ` Jack Mitchell
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=4FF329B2.1040101@palm.com \
--to=rich.pixley@palm.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=sgw@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