Our last sync with the kernel was 5.1. We are so out of sync now, that tracking the patches and backporting them one by one makes little sense and it's going to take ages. This is an attempt to sync up Makefiles to 6.1. Unfortunately due to sheer amount of patches this is not easy to review, but that's what we decided during a community call for the bump to 5.1, so we are following the same guidelines here. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>a #rebased on -next
The distutils package is deprecated. The upstream libfdt repo uses setuptools for building the pylibfdt module, so bring in that code, suitably modified for U-Boot. Also bring in the README. The modifications include setting the version correctly, making use of the environment variables provided by the Makefile and various tweaks to the directories. Note that the version omits the minus character at the start of EXTRAVERSION, since this creates a warning. The build is really just used within U-Boot itself, so it doesn't matter too much if the version matches upstream, or exactly matches U-Boot. Signed-off-by: Simon Glass <sjg@chromium.org>
python does not like the u-boot- prefix in the version, drop it.
/usr/lib/python3.10/site-packages/setuptools/dist.py:544: UserWarning:
The version specified ('u-boot-2022.10') is an invalid version, this may
not work as expected with newer versions of setuptools, pip, and PyPI.
Please see PEP 440 for more details.
Signed-off-by: Michal Suchanek <msuchanek@suse.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Some versions of make complain about using a grouped target without a recipe: .../pylibfdt/Makefile:36: *** grouped targets must provide a recipe. Stop. Fix this by adding a dummy recipe. Signed-off-by: Simon Glass <sjg@chromium.org>
At present the build rule for pylibfdt depends on _libfdt.so but modern Python versions add a different suffix to the output file, resulting in something like _libfdt.cpython-38-x86_64-linux-gnu.so The result is that pylibfdt is rebuilt every time. Rename the file the standard name so that the rule works correctly. Also add libfdt.py to the dependencies, so that file is always created if missing. Signed-off-by: Simon Glass <sjg@chromium.org>
If the pylibfdt shared-object file is detected, then Python assumes that the libfdt.py file exists also. Sometimes when an incremental build aborts, the shared-object file is built but the libfdt.py is not. The only way out at this point is to use 'make mkproper', or similar. Fix this by removing the .so file before it is built. This seems to make Python rebuild everything. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
This reverts commit 5d3a21df6694ebd66d5c34c9d62a26edc7456fc7, reversing changes made to 56d37f1c564107e27d873181d838571b7d7860e7. Unfortunately this is causing CI failures: https://travis-ci.org/github/trini/u-boot/jobs/711313649 Signed-off-by: Tom Rini <trini@konsulko.com>
If the pylibfdt shared-object file is detected, then Python assumes that the libfdt.py file exists also. Sometimes when an incremental build aborts, the shared-object file is built but the libfdt.py is not. The only way out at this point is to use 'make mkproper', or similar. Fix this by removing the .so file before it is built. This seems to make Python rebuild everything. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
Build this swig module with Python 3. Signed-off-by: Simon Glass <sjg@chromium.org>
pylibfdt needs Python 2 to build. Replace $(PYTHON) with $(PYTHON2) in pylibfdt Makefile to ensure Python 2 is used to build it. This fixes build on systems where Python 3 is the default version of the "python" interpreter. Reviewed-by: Simon Glass <sjg@chromium.org>