Hi On Wed, Oct 28, 2020 at 12:17 AM Rob Herring <robh@xxxxxxxxxx> wrote: > > On Tue, Oct 27, 2020 at 11:13 AM Marc-André Lureau > <marcandre.lureau@xxxxxxxxxx> 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". > > I've used meson in a couple of projects and it's still not quite in my > muscle memory. In any case, pretty much every project documents how to > build and install. > > > Would it help if configure & make wrap meson for you? > > I'd say only if that means dropping the bulk of the Makefiles. > > > Should we then drop the Makefile-based build system? > > What do most projects do? Distro packagers just deal with the change > when updating versions, or projects carry both until the main distros > have updated to meson builds? It depends, as meson is still a fairly recent build system. Early adopters had some transition period where both Makefile/autotools and meson were maintained side by side to ease that transition (iirc, mesa or glib), especially for older distro. But recently, a lot of projects have done a full switch (libvirt & qemu for example), even though they target quite ancient distro (up to 2y old-stable/LTS for example). They manage to do that in some cases by shipping meson as a submodule (or relying on pip at build-time in some distros perhaps). I don't remember checking which version is required by the meson.build proposed here. I can do that, if it helps. Then we can compare with what's available out of the box from various distros via https://repology.org/project/meson/versions. We can make it easier for the packager by wraping meson in configure & make shim, as done by various projects. But tbh, I don't think it helps the packager, as he still need to be aware that meson is required. And nowadays, there are various macros or declarative ways to package meson projects in various distros.
