[OE-core] local.conf & bblayers.conf changes...

[Mark Hatle]

On 7/3/12 12:47 PM, Martin Jansa wrote:
> 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

This affects ordering.. in my expample.. I wanted my layer to take precedence 
over the BBPATH is other layers.

> So typical BBPATH in layer.conf should be:
> BBPATH .= ":${LAYERDIR}"

It has to be := and not .=.  If it's not immediately resolved, then ${LAYERDIR} 
will go to undefined later.

If .= is working, I'm surprised.. the semantics may be different when processing 
BBPATH then other variables.

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

--Mark

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