Closed Maik93 closed 5 years ago
Hi @Maik93,
The container images do not contain poky or bitbake. It is up to you to clone those tools yourself. Usually what I have done is to just clone poky into the workdir I intend to use. For instance
myuser@/home/myuser% mkdir mystuff
myuser@/home/myuser% cd mystuff
myuser@/home/myuser/mystuff% git clone git://git.yoctoproject.org/poky
Cloning into 'poky'...
remote: Counting objects: 444810, done.
remote: Compressing objects: 100% (104984/104984), done.
remote: Total 444810 (delta 332849), reused 444566 (delta 332622)
Receiving objects: 100% (444810/444810), 156.54 MiB | 6.00 MiB/s, done.
Resolving deltas: 100% (332849/332849), done.
myuser@/home/myuser/mystuff% docker run --rm -it -v /home/myuser/mystuff:/workdir crops/poky --workdir=/workdir
pokyuser@ab3f37d51e0c:/workdir$ cd poky
pokyuser@ab3f37d51e0c:/workdir/poky$ . oe-init-build-env build
You had no conf/local.conf file. This configuration file has therefore been
created for you with some default values. You may wish to edit it to, for
example, select a different MACHINE (target hardware). See conf/local.conf
for more information as common configuration options are commented.
You had no conf/bblayers.conf file. This configuration file has therefore been created for you with some default values. To add additional metadata layers into your configuration please add entries to conf/bblayers.conf.
The Yocto Project has extensive documentation about OE including a reference manual which can be found at: http://yoctoproject.org/documentation
For more information about OpenEmbedded see their website: http://www.openembedded.org/
You can now run 'bitbake
Common targets are: core-image-minimal core-image-sato meta-toolchain meta-ide-support
You can also run generated qemu images with a command like 'runqemu qemux86' pokyuser@ab3f37d51e0c:/workdir/poky/build$ bitbake Nothing to do. Use 'bitbake world' to build everything, or run 'bitbake --help' for usage information. pokyuser@ab3f37d51e0c:/workdir/poky/build$
mm understood. Why you didn't integrate it on the Dockerfile
? If I do it, would you like that I send you a pull request?
One reason is that various versions of bitbake may not work with various versions of layers/metadata. While it may work, it is usually known what version of bitbake will be used with metadata, and users will often use repo, git submodules, or a similar method to associate a particular bitbake with their metadata.
Another reason is that if bitbake isn't in the same directory as oe-init-build-env, then oe-init-build-env will generate the follow message:
pokyuser@c02eaa8661a8:/workdir/oe-core$ . oe-init-build-env build
Error: The bitbake directory (/workdir/bitbake) does not exist! Please ensure a copy of bitbake exists at this location or specify an alternative path on the command line
The convention is that bitbake will be in the same directory as oe-init-build-env, and if it isn't then the BITBAKEDIR environment variable must be set to override that behavior. (I didn't see documentation for that variable, I only know about it because I looked at the script).
If bitbake was part of the container that means that BITBAKEDIR would also have to be set in the environment for it to work automatically. Then if the user wanted to follow the convention of bitbake being in the same directory as oe-init-build-env, they would first have to unset BITBAKEDIR.
As a core OE developer I'll second the point that Bitbake doesn't have a stable API, so there isn't any reason to embed a copy of bitbake inside the container. Your layers typically bring the correct release of bitbake that they require.
Understood, you've convinced me to not integrate bitbake, thank you for the explanation!
Hi, I've just tried to work with your image, following what you've written in the readme. Starting the container,
bitbake
cannot be found. I've tried to findoe-init-build-env
to source it, but I can't find it.