Re: [PATCH v5 2/3] build-sys: add meson build

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Hi

On Thu, Oct 22, 2020 at 8:17 AM David Gibson
<david@xxxxxxxxxxxxxxxxxxxxx> wrote:
>
> On Wed, Oct 21, 2020 at 11:05:09AM +0400, Marc-André Lureau wrote:
> > 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.
>
> Well, sure, but meson is not yet widespread enough that we can assume
> people know what that is.  The only meson project I'm familiar with is
> qemu, and I still invoke it via "make".

Would it help if configure & make wrap meson for you?

Should we then drop the Makefile-based build system?

>
> > 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.
>
> Ok, that helps substantially.  Still too wordy and non-obvious to
> invoke it though.

We could "make check" run the script in a more verbose way if we
decide to wrap meson build there.

>
> > 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.
>
> Well, sure, but when I started the dtc testsuite all the test
> frameworks I could find were so intimidating I never would have
> started writing actual tests if I'd tried to use them.

fwiw, I used BATS (https://github.com/sstephenson/bats) in some other
project that was using shell to test executables. I can investigate
that too for a future series if you don't mind relying on bash & git
submodules ;).





[Index of Archives]     [Device Tree]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux