[OE-core] local.conf & bblayers.conf changes...
Martin Jansa
martin.jansa at gmail.com
Tue Jul 3 17:47:02 UTC 2012
On Tue, Jul 03, 2012 at 12:35:35PM -0500, Mark Hatle wrote:
> On 7/3/12 12:19 PM, Rich Pixley wrote:
> > 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.
>
> BBPATH being relative doesn't affect what ends up in debug symbols, etc.
>
> The BBPATH needs to be absolute, within the scope of a single loaded session to
> avoid randomly included items, primarily from the CWD. This prevents
> non-repeatable builds.
>
> In a layer, the typical BBPATH is something like:
>
> BBPATH := "${LAYERDIR}:${BBPATH}"
No, please append to it, so order of layers in BBPATH is the same as
order of layers in BBLAYERS variable in bblayers.conf
So typical BBPATH in layer.conf should be:
BBPATH .= ":${LAYERDIR}"
This is now consistent in all layers I'm using and quick search in
layers I'm not using shows only meta-baryon having it vice versa.
Cheers,
>
> LAYERDIR is always the path to the layer being processed at any given time...
> so if a layer also provides addition scripts you can do:
>
> # Add scripts to PATH
> PATH := "${PATH}:${LAYERDIR}/scripts"
>
>
> As for the debug items, the system handles all of the debug symbols for you.
> All target symbols are referenced from the -root- of the target filesystem. If
> this is not happening in your builds, then you've disabled the debug symbol
> processing -- or you found a bug in the system... On the target side, debugging
> on the target that is, everything should 'just work' with no manual settings.
>
> On a remote debug, you just need to tell the system where the relative path is
> to the root of the filesystem you are debugging, gdb should then be able to add
> the references to the associated sources and .debug split items.
>
> This is all unchanged behavior for oe-core from when it was made oe-core to present.
>
> > 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
>
> If it says MACHINE isn't configured, then you are lacking a proper BSP/machine
> configuration file.
>
> There are a couple of checks, but in the end they resolve down to checking that
> TUNE_ARCH, TARGET_OS, and TUNE_PKGARCH exit and are reasonable, as well as
> conf/machine/${MACHINE}.conf can be loaded.
>
> Any of the above items not found or not configured properly indicate MACHINE
> isn't defined, or the conf/machine/${MACHINE}.conf doesn't exist -- or is
> incorrectly configured.
>
> > 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?
>
> bblayers shouldn't affect your machine files, other then a layer may contain a
> conf/machine/...conf file. The BBPATH setting of ${LAYERDIR} allows this
> directory to be automatically scanned when requesting a conf file.
>
> --Mark
>
> > --rich
> >
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core at lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
--
Martin 'JaMa' Jansa jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20120703/9c0ddf26/attachment-0002.sig>
More information about the Openembedded-core
mailing list