Re: local.conf & bblayers.conf changes...

[Martin Jansa <martin.jansa@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5208 bytes --]

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@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]