Hi On Wed, Oct 21, 2020 at 7:58 AM David Gibson <david@xxxxxxxxxxxxxxxxxxxxx> wrote: > > On Mon, Oct 12, 2020 at 11:34:04AM +0400, marcandre.lureau@xxxxxxxxxx wrote: > > From: Marc-André Lureau <marcandre.lureau@xxxxxxxxxx> > > > > 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@xxxxxxxxxx> > > Can you add some docs on how to actually invoke the meson build. The > next patch suggests "meson build", but for me that seems to just > configure but not actually build anything: Sure, the way to invoke it is just like a regular meson project. I will add some notes to the README. > > $ meson build > The Meson build system > Version: 0.55.3 > Source dir: /home/dwg/src/dtc > Build dir: /home/dwg/src/dtc/build > Build type: native build > Project name: dtc > Project version: 1.6.0 > C compiler for the host machine: ccache cc (gcc 10.2.1 "cc (GCC) 10.2.1 20200723 (Red Hat 10.2.1-1)") > C linker for the host machine: cc ld.bfd 2.34-5 > Host machine cpu family: x86_64 > Host machine cpu: x86_64 > Compiler for C supports arguments -Wall: YES > Compiler for C supports arguments -Wpointer-arith: YES > Compiler for C supports arguments -Wcast-qual: YES > Compiler for C supports arguments -Wnested-externs: YES > Compiler for C supports arguments -Wstrict-prototypes: YES > Compiler for C supports arguments -Wmissing-prototypes: YES > Compiler for C supports arguments -Wredundant-decls: YES > Compiler for C supports arguments -Wshadow: YES > meson.build:18: WARNING: Consider using the built-in warning_level option instead of using "-Wall". > Found pkg-config: /bin/pkg-config (1.6.3) > Run-time dependency yaml-0.1 found: YES 0.2.2 > Run-time dependency valgrind found: NO (tried pkgconfig) > Program python3 found: YES (/usr/bin/python3) > Program swig found: YES > Found git repository at /home/dwg/src/dtc > Compiler for C supports link arguments -Wl,--version-script=/home/dwg/src/dtc/libfdt/version.lds: YES > Program flex found: YES > Program bison found: YES > Check usable header "fnmatch.h" : YES > Program setup.py found: YES > Program /home/dwg/src/dtc/pylibfdt/setup.py found: YES (/home/dwg/src/dtc/pylibfdt/setup.py) > Library dl found: YES > Program run_tests.sh found: YES > Build targets in project: 81 > > Found ninja-1.10.1 at /bin/ninja > > Having to run "ninja -C build test" to run the tests is then pretty > horrible. Especially since it doesn't actually show the test summary > from run_tests.sh unless you delve into the logs. If an error occurred, it would print it on the console. But to get a summary on success, you have to look at the log: run_tests.sh isn't very nice for meson. It would be better if it provided TAP output, or even better probably, if the tests would be run by meson. > > -- > David Gibson | I'll have my music baroque, and my code > david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ > | _way_ _around_! > http://www.ozlabs.org/~dgibson
