It would be nice to have a variable for getting the poky root, basically the "oe" script that sets up the bitbake environment. I would imagine terms like PROJECTDIR, ROOTDIR, or something similar for this. The typical usage at first would be the bblayers.conf to be working across developers, and even on the CI. Currently, I am using a workaround something like this: ${TOPDIR}/../meta \ ${TOPDIR}/../meta-yocto \ ${TOPDIR}/../meta-yocto-bsp \ ... but the ".." parenting looks strange, especially since it is clear where the "oe-init-build-env" script resides.
This particular layout is specific to poky, the system is generic and the layers can be placed anywhere, as can bitbake and the build directories. There is already the COREBASE directory which tells you where the meta directory is. Assuming the presence of any other layer would be a bad thing as it means the code using it would rely on specific layouts. The build directory defaults to the build directory but can also be placed anywhere and poky allows configuration of that using a parameter to the oe-init-build-env script. Assuming TOPDIR/.. as mentioned elsewhere is therefore also a bad idea. I'm therefore not convinced that having a variable for "poky root" would be a good thing, or encourage good (portable) usage of the system either.
It would make a lot of sense to expose the meta layer actually, even if it is not inside the bitbake stuff, but through the "oe-init-build-env" script. I really do not understand how this can be a bad idea when it is a fixed layout dictated by poky. So, even if someone does not use something relatively close to the meta layer folder, it entirely makes sense to aid the default built-in layers at least. If there is such a variable already existing, surely, it would need to be documented, so the bugreport makes sense to me either way.
COREBASE is the location of meta/ (oe-core). If you're willing to make the assumption that all of the layers are alongside each other, you can use this to hop between layers. Re-assigning to Scott to get this variable in the variable glossary. "COREBASE: the location of the meta/ directory from oe-core."
Sorry, but you are wrong. I have not asked for that variable. That seems to be the matter of another bugreport as that is a different documentation issue. I would still like Poky giving me the poky project or root dir. This bugreport was opened for that, so please revert your changes, and open a separate bugreport for another issue if you wish.
bug 4981 created.
As a concrete example, this is the bblayers for my current build: BBLAYERS ?= " \ /home/ross/Yocto/poky/meta \ /home/ross/Yocto/poky/meta-yocto \ /home/ross/Yocto/poky/meta-yocto-bsp \ /home/ross/Yocto/meta-oe/meta-oe \ /home/ross/Yocto/meta-oe/meta-multimedia \ /home/ross/Yocto/meta-intel \ /home/ross/Yocto/meta-intel/meta-nuc \ /home/ross/Yocto/meta-ross" In this case I don't have an obvious "root". However if you are making the assumption/have the knowledge that you're putting all layers along side each other then you can use COREBASE as a known and fixed root (in this case, it is set to /home/ross/Yocto/poky). In the context of a bblayers.conf.sample file that your layer can provide, you can use ##COREBASE## that will be substituted for you (see meta-yocto/conf/bblayers.conf.sample). As Richard pointed out, using TOPDIR isn't a good idea as you can change that to anything by passing a path to oe-init-build-env.
As I mentioned before already, actually in my initial post, TOPDIR was the only sane documented variable to get as close to what people wish as possible. I will verify later, and close if it works.
As another concrete example I'll show why TOPDIR isn't what you want: $ mkdir --parents /tmp/test/directory/a/long/way $ cd ~/Yocto/poky $ . oe-init-build-env /tmp/test/directory/a/long/way [...] $ bitbake zlib -e |grep TOPDIR= TOPDIR="/tmp/test/directory/a/long/way" Re-resolving resolved, please only re-open when you've evidence that using COREBASE doesn't work and an alternative proposal that hasn't already been discussed.
Why do you write the obvious? It is crystal clear for everyone (I really hope) that only that crap is documented as the closest opportunity for end users. That should kinda give you the idea how severe it is to fix 4981. Not to mention, ##COREBASE## has been broken last time when I tried, so let us not play your preferred ping-pong game here, too. It will be caused once it is tested thoroughly, and proven working despite the non-function past behavior.
Also, any reason why it is ##COREBASE## instead of simply ${COREBASE} to be inline with the rest on top of also being shorter to write?
I tried ${COREBASE} shortly, but it did not work at the company. I could probably provide logs later, but is there any theoretical reason why that could not work?
Depends on the context, an example would be needed. Also, this discussion is probably best for the yocto@ list.
It is an improvement suggestion, so in my opinion, bugzilla is fine. Not sure what context you can confuse you. We have only discussed one here for the bblayers.
So for layers, you can provide a bblayers.conf.sample in your distro. That uses ##COREBASE## which is substituted during oe-init-build-env with the correct paths. In bblayers.conf you can't use ${COREBASE} as that's provided by the meta layer, which hasn't been parsed yet.
So, we are back then to my original question? Cannot Poky provide the poky root for me? I would prefer a ${VARIABLE} syntax as that is shorter and more consistent with the rest.
The variable doesn't use ${FOO} because it's not expanded like ${FOO}, but substituted when oe-init-build-env runs, which for layer configuration is exactly what you want.
I understood that, and that was not a doubt why it is ##COREBASE##. Still, I prefer poky providing me the root dir and I can type less, and also be consistent with the variable usage in general.
It turns out that ${COREBASE} and ##COREBASE## can point at different locations, so I've sent a patch that deprecates ##COREBASE## and adds ##OEROOT##, which is defined as the directory which contains oe-init-build-env. This has precise semantics unlike COREBASE so is just right for use in bblayer.conf.sample files.
Thanks for your work. Could you please paste a send to the change?
I tried to put the ##COREBASE## directive into my bblayers.conf sample in my distro/bsp layer, but source the open embedded init script only created the bblayers.conf file based upon the meta-yocto layer's sample. Is there any particular reason why my layer's sample does not get that overriden?
You need to tell the script what layer you want to use as the template location. Add TEMPLATECONF=meta-foo/conf to the top-level oe-init-build-env script and it will use that layer instead of meta-yocto (for Poky builds) or meta (for oe-core builds).
So now this bug is basically that the per-layer samples/templates need to be documented. The files are $TEMPLATECONF/bblayers.conf.sample and $TEMPLATECONF/local.conf.sample, where TEMPLATECONF defaults to meta/conf in oe-core builds and meta-yocto/conf in Poky builds. The files are ran through a sed so that any ##OEROOT## instances are replaced with the final ${OEROOT} value (i.e. the directory where oe-init-build-env was sourced from). Assigning to Scott and changing status to reflect.
Hi, I have implemented some doc changes to try and address this. I added more detail to the reference sections that describe the bblayers.conf and local.conf configuration files. I also added a glossary entry for OEROOT. Here are the links for review: http://www.yoctoproject.org/docs/1.5/ref-manual/ref-manual.html#structure-build-conf-local.conf http://www.yoctoproject.org/docs/1.5/ref-manual/ref-manual.html#structure-build-conf-bblayers.conf http://www.yoctoproject.org/docs/1.5/ref-manual/ref-manual.html#var-OEROOT Please review and let me know of any changes/additions, etc. Thanks, Scott
Looks fine to me, thanks Scott.
Hi, Marking RESOLVED.
Thanks Scott. On the first link: "The source local.conf.sample file used depends on the $TEMPLATECONF script variable, which defaults to /meta-yocto/conf when you are building from the Yocto Project development environment and defaults to /meta/conf when you are building from the OpenEmbedded Core environment. Because the script variable points to the source of the local.conf.sample file, this implies that you can configure your build environment from any layer by setting the variable in the top-level build environment setup script as follows: TEMPLATECONF=<your_layer>/conf" I would personally drop the leading spaces in "/meta-yocto/conf" and "/meta/conf". That would be more indicative that these are "relative paths". I would personally make the same change on the other two links, too. Otherwise, it looks good, and thank you for your help.
Sorry, I meant leading "forward slash" as opposed to "space". Apologies for the typo.
Hi Laszlo, These changes are in the 1.6 (latest) and the 1.5.1 versions of the manuals. Paul also indicated to me sometime back that I should not be prefixing these types of paths with the slash. So I had addressed that earlier. Unfortunately, when this bug was first being worked it was against the 1.5 versions of the manuals. So the links in the historical comments here point to versions that did not get corrected. Anyway... the changes are now in both branches of the docs that are being worked. I did make a new slight change to the OEROOT description. The wording I had was poor as it said "... resolves to the directory that holds the script." I changed that to "... resolves to the directory that contains the script." Here are the links to wrap this up so you can see that indeed the changes had been made. http://www.yoctoproject.org/docs/1.6/ref-manual/ref-manual.html#structure-build-conf-local.conf http://www.yoctoproject.org/docs/1.6/ref-manual/ref-manual.html#structure-build-conf-bblayers.conf http://www.yoctoproject.org/docs/1.6/ref-manual/ref-manual.html#var-OEROOT Thanks, Scott
Ah, ok, great!