crops / poky-container

A container image that is able to run bitbake/poky. It has helpers to create users and groups within the container. This is so that the output generated in the container will be readable by the user on the host.
GNU General Public License v2.0
206 stars 94 forks source link

bitbake not found #36

Closed Maik93 closed 5 years ago

Maik93 commented 5 years ago

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 find oe-init-build-env to source it, but I can't find it.

rewitt1 commented 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

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/

Shell environment set up for builds.

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$

Maik93 commented 5 years ago

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?

rewitt1 commented 5 years ago

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.

rossburton commented 5 years ago

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.

Maik93 commented 5 years ago

Understood, you've convinced me to not integrate bitbake, thank you for the explanation!