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

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



On Tue, Oct 27, 2020 at 08:09:39PM +0400, Marc-André Lureau wrote:
> 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?

That sounds like it could be a good idea.  Although there is no
"configure" for dtc.

> 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.

I guess.  It concerns me if there's no more succinct "meson native"
way of invoking the tests.

> > > 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 ;).

Patches considered, but I absolutely do not have time to tackle
porting the dtc testsuite to a different framework myself.

-- 
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

Attachment: signature.asc
Description: PGP signature


[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