a19b822239
pybind11 is not really a Python module; it is actually a set of headers that is used to wrap Python objects in C++. Since pybind version 2.6.1, it uses CMake internally. This causes a number of build issues for Buildroot because either no cmake is present or it is too old. pybind in fact has three parts: the C++ headers, a python module pybind11, and the tests. The python package's only purpose is to serve as a configure script for users of pybind. CMake is mainly used to build and run the tests, which use the (mock-installed) pybind11 module to find the (mock-installed) C++ headers. CMake is also used to install the headers. The setup.py script calls into CMake to install the headers and CMake support files to a temporary directory, then copies that together with the pybind11 module into the Python directory. The pybind11 module then returns the include and cmake paths relative to its install location (using __file__ to determine the install location). This is not at all compatible with how Buildroot expects things to be organised. - The include and CMake files are installed somewhere within the Python directories, where nobody will find them. - The Python module is installed for the target, but at build time Python modules are read from the host directory only. Therefore, a user of pybind can't actually load the module. To solve this, several options are possible: - Treat pybind as a host package. This causes users of pybind to build with an include path pointing into the host directory. This happens to work because pybind is a header-only library and because it is installed in a specific location which is not contaminated by other headers. However, it is philosophically wrong - a build for the target should never have an include path pointing to the host directory. - Install pybind in the usual way into staging, and add a stub module to the host directory that returns paths to the staging directory. This leaves a useless pybind11 module in the staging directory, and puts the headers and cmake files in an unusual location. In addition it is not so simple - we need to jump through hoops to make sure that cmake is called correctly when it goes through python-package. - Install the headers and cmake files using CMake, and add a (stub) python module in the host directory that points users to the staging directory. This puts the headers in the usual place (STAGING_DIR/usr/include) and still makes it possible to find them from a python package at build time. We choose the latter solution. First of all, convert to cmake-package. This installs just the headers and the cmake support files. We need to pass PYBIND11_NOPYTHON=ON because there is a cmake module that tries to find the python binary. It sometimes finds the system python, sometimes the host python. In either case, it checks whether this python's bitness and endianness correspond to that of the compiler - which generally it doesn't in cross-compilation. PYBIND_NOPYTHON bypasses this check. Install in staging and not in target. Before, it was installed to target but the python module would point to the target directory so it worked anyway; now, however, we can properly use the staging directory. Since it is no longer a python-package, the python module is not installed automatically. Install them manually in a post-staging-install hook. Since the python module is supposed to be used at build time, install it in the host directory rather than in staging. The python module normally looks in its current directory to find the include and cmake paths, but for cross-compilation this is wrong. Add a non-upstreamable patch that checks for STAGING_DIR in the environment. If it is set (which is the case in Buildroot), use that instead of the current directory. Add an explicit dependency on python3. The headers include Python.h, so any user of pybind needs to implicitly depend on python3. While we're at it, change it to support python3 only - even though pybind currently still supports python2, adding support for it in Buildroot is a little bit complicated and python2 will be removed soon anyway. Cc: Esben Haabendal <esben@geanix.com> Cc: Andreas Naumann <dev@andin.de> Co-Developed-by: Jagan Teki <jagan@amarulasolutions.com> Co-Developed-by: Guillaume W. Bres <guillaume.bressaix@gmail.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> |
||
|---|---|---|
| arch | ||
| board | ||
| boot | ||
| configs | ||
| docs | ||
| fs | ||
| linux | ||
| package | ||
| support | ||
| system | ||
| toolchain | ||
| utils | ||
| .clang-format | ||
| .defconfig | ||
| .flake8 | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| CHANGES | ||
| Config.in | ||
| Config.in.legacy | ||
| COPYING | ||
| DEVELOPERS | ||
| Makefile | ||
| Makefile.legacy | ||
| README | ||
Buildroot is a simple, efficient and easy-to-use tool to generate embedded Linux systems through cross-compilation. The documentation can be found in docs/manual. You can generate a text document with 'make manual-text' and read output/docs/manual/manual.text. Online documentation can be found at http://buildroot.org/docs.html To build and use the buildroot stuff, do the following: 1) run 'make menuconfig' 2) select the target architecture and the packages you wish to compile 3) run 'make' 4) wait while it compiles 5) find the kernel, bootloader, root filesystem, etc. in output/images You do not need to be root to build or run buildroot. Have fun! Buildroot comes with a basic configuration for a number of boards. Run 'make list-defconfigs' to view the list of provided configurations. Please feed suggestions, bug reports, insults, and bribes back to the buildroot mailing list: buildroot@buildroot.org You can also find us on #buildroot on OFTC IRC. If you would like to contribute patches, please read https://buildroot.org/manual.html#submitting-patches