kernel
/
dtc
mirror of https://git.kernel.org/pub/scm/utils/dtc/dtc.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1163 Commits
2 Branches
23 Tags
1.7 MiB
Tree: 61e88fdcec
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '61e88fdcec'
${ noResults }
dtc/pylibfdt/meson.build

14 lines
389 B
Raw Normal View History Unescape

pylibfdt: Move setup.py to the top level Using 'pip' and several setup.py sub-commands currently don't work with pylibfdt. The primary reason is Python packaging has opinions on the directory structure of repositories and one of those appears to be the inability to reference source files outside of setup.py's subtree. This means a sdist cannot be created with all necessary source components (i.e. libfdt headers). Moving setup.py to the top-level solves these problems. With this change. the following commands now work: Creating packages for pypi.org: ./setup.py sdist bdist_wheel Using pip for installs: pip install . pip install git+http://github.com/robherring/dtc.git@pypi-v2 Signed-off-by: Rob Herring <robh@kernel.org> Message-Id: <20211111011135.2386773-5-robh@kernel.org> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
3 years ago
setup_py = find_program('../setup.py')
pylibtfdt: fix use of deprecated meson method Fixes the following warning > pylibfdt/meson.build:2: WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead Do not use full_path() as suggested. setup_py is being called as a command by custom_target() which understands how to properly inherit the object returned by find_program(). Signed-off-by: Brandon Maier <brandon.maier@collins.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
1 year ago
setup_py = [setup_py, '--quiet', '--top-builddir', meson.project_build_root()]
build-sys: add meson build The meson build system allows projects to "vendor" dtc easily, thanks to subproject(). QEMU has recently switched to meson, and adding meson support to dtc will help to handle the QEMU submodule. meson rules are arguably simpler to write and maintain than the hand-crafted/custom Makefile. meson support various backends, and default build options (including coverage, sanitizer, debug/release etc, see: https://mesonbuild.com/Builtin-options.html) Compare to the Makefiles, the same build targets should be built and installed and the same tests should be run ("meson test" can be provided extra test arguments for running the equivalent of checkm/checkv). There is no support EXTRAVERSION/LOCAL_VERSION/CONFIG_LOCALVERSION, instead the version is simply set with project(), and vcs_tag() is used for git/dirty version reporting (This is most common and is hopefully enough. If necessary, configure-time options could be added for extra versioning.). libfdt shared library is build following regular naming conventions: instead of libfdt.so.1 -> libfdt-1.6.0.so (with current build-sys), libfdt.so.1 -> libfdt.so.1.6.0. I am not sure why the current build system use an uncommon naming pattern. I also included a libfdt.pc pkg-config file, as convenience. Both Linux native build and mingw cross-build pass. CI pass. Tests are only run on native build. The current Makefiles are left in-tree, and make/check still work. Eventually, the Makefiles could be marked as deprecated, to start a transition period and avoid having to maintain 2 build systems in the near future. (run_tests.sh could eventually be replaced by the meson test runner, which would have several advantages in term of flexibility/features, but this is left for another day) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20201012073405.1682782-3-marcandre.lureau@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
4 years ago
meson: fix dependencies of tests If the tests are run without a full compile they will fail. For example with the following. > rm -rf build/ > meson setup build/ > meson test -C build/ This is because the tests rely on the devicetree tools and test executables. Signed-off-by: Brandon Maier <brandon.maier@collins.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
7 months ago
pylibfdt = custom_target(
build-sys: add meson build The meson build system allows projects to "vendor" dtc easily, thanks to subproject(). QEMU has recently switched to meson, and adding meson support to dtc will help to handle the QEMU submodule. meson rules are arguably simpler to write and maintain than the hand-crafted/custom Makefile. meson support various backends, and default build options (including coverage, sanitizer, debug/release etc, see: https://mesonbuild.com/Builtin-options.html) Compare to the Makefiles, the same build targets should be built and installed and the same tests should be run ("meson test" can be provided extra test arguments for running the equivalent of checkm/checkv). There is no support EXTRAVERSION/LOCAL_VERSION/CONFIG_LOCALVERSION, instead the version is simply set with project(), and vcs_tag() is used for git/dirty version reporting (This is most common and is hopefully enough. If necessary, configure-time options could be added for extra versioning.). libfdt shared library is build following regular naming conventions: instead of libfdt.so.1 -> libfdt-1.6.0.so (with current build-sys), libfdt.so.1 -> libfdt.so.1.6.0. I am not sure why the current build system use an uncommon naming pattern. I also included a libfdt.pc pkg-config file, as convenience. Both Linux native build and mingw cross-build pass. CI pass. Tests are only run on native build. The current Makefiles are left in-tree, and make/check still work. Eventually, the Makefiles could be marked as deprecated, to start a transition period and avoid having to maintain 2 build systems in the near future. (run_tests.sh could eventually be replaced by the meson test runner, which would have several advantages in term of flexibility/features, but this is left for another day) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20201012073405.1682782-3-marcandre.lureau@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
4 years ago
'pylibfdt',
input: 'libfdt.i',
meson: fix pylibfdt missing dependency on libfdt The python library requires libfdt to build. This would intermittently fail depending on what order targets compiled. Signed-off-by: Brandon Maier <brandon.maier@collins.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
7 months ago
depends: libfdt,
build-sys: add meson build The meson build system allows projects to "vendor" dtc easily, thanks to subproject(). QEMU has recently switched to meson, and adding meson support to dtc will help to handle the QEMU submodule. meson rules are arguably simpler to write and maintain than the hand-crafted/custom Makefile. meson support various backends, and default build options (including coverage, sanitizer, debug/release etc, see: https://mesonbuild.com/Builtin-options.html) Compare to the Makefiles, the same build targets should be built and installed and the same tests should be run ("meson test" can be provided extra test arguments for running the equivalent of checkm/checkv). There is no support EXTRAVERSION/LOCAL_VERSION/CONFIG_LOCALVERSION, instead the version is simply set with project(), and vcs_tag() is used for git/dirty version reporting (This is most common and is hopefully enough. If necessary, configure-time options could be added for extra versioning.). libfdt shared library is build following regular naming conventions: instead of libfdt.so.1 -> libfdt-1.6.0.so (with current build-sys), libfdt.so.1 -> libfdt.so.1.6.0. I am not sure why the current build system use an uncommon naming pattern. I also included a libfdt.pc pkg-config file, as convenience. Both Linux native build and mingw cross-build pass. CI pass. Tests are only run on native build. The current Makefiles are left in-tree, and make/check still work. Eventually, the Makefiles could be marked as deprecated, to start a transition period and avoid having to maintain 2 build systems in the near future. (run_tests.sh could eventually be replaced by the meson test runner, which would have several advantages in term of flexibility/features, but this is left for another day) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20201012073405.1682782-3-marcandre.lureau@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
4 years ago
output: '_libfdt.so',
pylibfdt/meson.build: fix Python library being rebuilt during install User @sharkcz noted that when the '--quiet' flag is removed from ./setup.py, the following can be seen from the `./setup.py install` stage. Running custom install script 'dtc/g/pylibfdt/../setup.py --top-builddir \ dtc/g/redhat-linux-build install --prefix=/usr/local --root=$DESTDIR' running install ... building '_libfdt' extension swigging dtc/g/pylibfdt/../pylibfdt/libfdt.i to \ dtc/g/pylibfdt/../pylibfdt/libfdt_wrap.c swig -python -Idtc/g/pylibfdt/../libfdt -o \ dtc/g/pylibfdt/../pylibfdt/libfdt_wrap.c dtc/g/pylibfdt/../pylibfdt/libfdt.i gcc -fno-strict-overflow -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 \ -DNDEBUG -fexceptions -fexceptions -fexceptions -fPIC -DPY_SSIZE_T_CLEAN \ -Idtc/g/pylibfdt/../libfdt -I/usr/include/python3.12 -c \ dtc/g/pylibfdt/../pylibfdt/libfdt_wrap.c -o \ build/temp.linux-ppc64le-cpython-312dtc/g/pylibfdt/../pylibfdt/libfdt_wrap.o creating build/lib.linux-ppc64le-cpython-312 gcc -shared build/temp.linux-ppc64le-cpython-312dtc/g/pylibfdt/../pylibfdt/libfdt_wrap.o \ -Ldtc/g/redhat-linux-build/libfdt -L/usr/lib64 -lfdt -o \ build/lib.linux-ppc64le-cpython-312/_libfdt.cpython-312-powerpc64le-linux-gnu.so copying dtc/g/pylibfdt/../pylibfdt/libfdt.py -> build/lib.linux-ppc64le-cpython-312 Meaning the python library is getting recompiled during the `meson install` phase. This causes build issues as Meson does not set the compiler and linker flags during the install phase. The reason the library is getting rebuilt is during the normal build with "build_ext", the `--build-lib` flag gets passed which changes the default output build directory. But there is no equivalent option for the "install" command. Install instead looks in the default directory "./build" and so does not find the previously built library. Since we can't fix the "install" command, drop the --build-lib flag. This causes setup.py to compile the libraries at `<meson-build>/build/lib.linux-x86_64-cpython-312/`. We must also then fix run_tests.sh to find the library build directory as it's machine-dependent. Fixes: #135 Signed-off-by: Brandon Maier <brandon.maier@gmail.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
4 months ago
command: [setup_py, 'build_ext'],
build-sys: add meson build The meson build system allows projects to "vendor" dtc easily, thanks to subproject(). QEMU has recently switched to meson, and adding meson support to dtc will help to handle the QEMU submodule. meson rules are arguably simpler to write and maintain than the hand-crafted/custom Makefile. meson support various backends, and default build options (including coverage, sanitizer, debug/release etc, see: https://mesonbuild.com/Builtin-options.html) Compare to the Makefiles, the same build targets should be built and installed and the same tests should be run ("meson test" can be provided extra test arguments for running the equivalent of checkm/checkv). There is no support EXTRAVERSION/LOCAL_VERSION/CONFIG_LOCALVERSION, instead the version is simply set with project(), and vcs_tag() is used for git/dirty version reporting (This is most common and is hopefully enough. If necessary, configure-time options could be added for extra versioning.). libfdt shared library is build following regular naming conventions: instead of libfdt.so.1 -> libfdt-1.6.0.so (with current build-sys), libfdt.so.1 -> libfdt.so.1.6.0. I am not sure why the current build system use an uncommon naming pattern. I also included a libfdt.pc pkg-config file, as convenience. Both Linux native build and mingw cross-build pass. CI pass. Tests are only run on native build. The current Makefiles are left in-tree, and make/check still work. Eventually, the Makefiles could be marked as deprecated, to start a transition period and avoid having to maintain 2 build systems in the near future. (run_tests.sh could eventually be replaced by the meson test runner, which would have several advantages in term of flexibility/features, but this is left for another day) Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Message-Id: <20201012073405.1682782-3-marcandre.lureau@redhat.com> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
4 years ago
build_by_default: true,
)
meson.add_install_script(setup_py, 'install', '--prefix=' + get_option('prefix'), '--root=$DESTDIR')