ea4b963d9a
The implementation of BUILDHISTORY_RESET is problematic, particlarly given that people are trying to create an API with it alongside BUILDHISTORY_PRESERVE which simply doesn't exist and can't work reliably. Worse, the code paths with this bolted on implementation are convoluted and near impossible to follow. BUILDHISTORY_PRESERVE is effectively internal API, used to stop buildhistory removing some files which are needed for data, or are created at different parts of the build. Add a comment to explain what it is doing and why these files are listed. Commit 9f68a45aa238ae5fcdfaca71ba0e7015e9cb720e tried to "fix" preserve support with the reset functionality but it didn't fully work and has just exposed futher issues. There is a further fix however I can brely follow the code and in reviewing it, I've concluded we shouldn't be doing this at all. Due to the way BUILDHISTORY_RESET was implemented, horrible races were introduced making it unclear what happens to the data if builds fail for example, or how sstate interacts with the build since things get reset but stamps do not and tasks may not rerun. It also interacts badly with any additions to the preserve list, due to misunderstandings on what that variable does. Having stared long and hard at the code, and really struggled to understand it, I', of the view that "reset" for CI purposes should be done by the CI itself. The CI can choose to remove some files or all files and decide how to handle failures. It has to handle the buildhistory directory anyway. Therefore drop BUILDHISTORY_RESET support, allowing the "old" codepaths to be dropped. BUILDHISTORY_PRESERVE is better documented to hint that it is internal API and to show what it is really for. If we really do want some functionality list this, it needs to be implemented in a way you can follow the code, and have tests. (From OE-Core rev: 15c5258fd0063ace425b7e904521f1695ffb2a85) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> |
||
|---|---|---|
| bitbake | ||
| contrib | ||
| documentation | ||
| meta | ||
| meta-poky | ||
| meta-selftest | ||
| meta-skeleton | ||
| meta-yocto-bsp | ||
| scripts | ||
| .b4-config | ||
| .gitignore | ||
| .templateconf | ||
| LICENSE | ||
| LICENSE.GPL-2.0-only | ||
| LICENSE.MIT | ||
| MAINTAINERS.md | ||
| MEMORIAM | ||
| oe-init-build-env | ||
| README.hardware.md | ||
| README.md | ||
| README.OE-Core.md | ||
| README.poky.md | ||
| README.qemu.md | ||
| SECURITY.md | ||
Poky
Poky is an integration of various components to form a pre-packaged build system and development environment which is used as a development and validation tool by the Yocto Project. It features support for building customised embedded style device images and custom containers. There are reference demo images ranging from X11/GTK+ to Weston, commandline and more. The system supports cross-architecture application development using QEMU emulation and a standalone toolchain and SDK suitable for IDE integration.
Additional information on the specifics of hardware that Poky supports is available in README.hardware. Further hardware support can easily be added in the form of BSP layers which extend the systems capabilities in a modular way. Many layers are available and can be found through the layer index.
As an integration layer Poky consists of several upstream projects such as BitBake, OpenEmbedded-Core, Yocto documentation, the 'meta-yocto' layer which has configuration and hardware support components. These components are all part of the Yocto Project and OpenEmbedded ecosystems.
The Yocto Project has extensive documentation about the system including a reference manual which can be found at https://docs.yoctoproject.org/
OpenEmbedded is the build architecture used by Poky and the Yocto project. For information about OpenEmbedded, see the OpenEmbedded website.
Contribution Guidelines
Please refer to our contributor guide here: https://docs.yoctoproject.org/dev/contributor-guide/ for full details on how to submit changes.
Where to Send Patches
As Poky is an integration repository (built using a tool called combo-layer), patches against the various components should be sent to their respective upstreams:
OpenEmbedded-Core (files in meta/, meta-selftest/, meta-skeleton/, scripts/):
- Git repository: https://git.openembedded.org/openembedded-core/
- Mailing list: openembedded-core@lists.openembedded.org
BitBake (files in bitbake/):
- Git repository: https://git.openembedded.org/bitbake/
- Mailing list: bitbake-devel@lists.openembedded.org
Documentation (files in documentation/):
- Git repository: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-docs/
- Mailing list: docs@lists.yoctoproject.org
meta-yocto (files in meta-poky/, meta-yocto-bsp/):
- Git repository: https://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto
- Mailing list: poky@lists.yoctoproject.org
If in doubt, check the openembedded-core git repository for the content you intend to modify as most files are from there unless clearly one of the above categories. Before sending, be sure the patches apply cleanly to the current git repository branch in question.