[Libosinfo] [osinfo-db-tools PATCH 2/8] Add support to meson build system

[Fabiano Fidêncio]

On Thu, Jun 20, 2019 at 6:42 PM Pavel Hrdina <phrdina at redhat.com> wrote:
>
> On Thu, Jun 20, 2019 at 05:21:21PM +0200, Fabiano Fidêncio wrote:
> > Meson build system is a way simpler and easier to understand build
> > system that can provide (with some work-arounds here and there) the same
> > functionalities currently available with our current build system
> > (autotools).
> >
> > For now, as meson support is not fully complete* and requires a quite
> > new version of meson still not present in all systems supported on
> > libvirt-jenkis-ci, let's keep autotools around so more extensive testing
> > if meson's functionalities can be done before actually removing
> > autotools support.
> >
> > *: the support is not fully complete as there's still no equivalent of
> > `make syntax-check` provided.
> >
> > A quite nice description of meson, ninja, and their workflow was part of
> > the spice* commits introducing support to meson/ninja and is copied
> > below:
> > ```
> > - Meson: https://mesonbuild.com
> >
> >   This is the equivalent of autogen/configure step in autotools. It
> >   generates the files that will be used by ninja to actually build the
> >   source code.
> >
> >   The project has received lots of traction recently, with many GNOME
> >   projects willing to move to this new build system. The following wiki
> >   page has more details of the status of the many projects being ported:
> >
> >     https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting
> >
> >   Meson has a python-like syntax, easy to read, and the documentation
> >   on the project is very complete, with a dedicated page on how to port
> >   from autotools, explaining how most common use cases can be
> >   implemented using meson.
> >
> >     http://mesonbuild.com/Porting-from-autotools.html
> >
> >   Other important sources of information:
> >
> >     http://mesonbuild.com/howtox.html
> >     http://mesonbuild.com/Syntax.html
> >     http://mesonbuild.com/Reference-manual.html
> >
> > - Ninja: https://ninja-build.org
> >
> >   Ninja is the equivalent of make in an autotools setup, which actually
> >   builds the source code. It has being used by large and complex
> >   projects such as Google Chrome, Android and LLVM. There is not much to
> >   say about ninja (other than it is much faster than make) because we
> >   won't interact directly with it as much, as meson does the middle man
> >   job here. The reasoning for creating ninja in the first place is
> >   explained on the following post:
> >
> >     http://neugierig.org/software/chromium/notes/2011/02/ninja.html
> >
> >   Also its manual provides more in-depth information about the design
> >   principles:
> >
> >     https://ninja-build.org/manual.html
> >
> > - Basic workflow:
> >
> >   Meson package is available for most if not all distros, so, taking
> >   Fedora as an example, we only need to run:
> >
> >     # dnf -y install meson ninja-build.
> >
> >   With Meson, building in-tree is not possible at all, so we need to
> >   pass a directory as argument to meson where we want the build to be
> >   done. This has the advantage of creating builds with different options
> >   under the same parent directory, e.g.:
> >
> >     $ meson ./build --prefix=/usr
> >     $ meson ./build-extra -Dextra-checks=true -Dalignment-checks=true
> >
> >   After configuration is done, we call ninja to actually do the build.
> >
> >     $ ninja -C ./build
> >     $ ninja -C ./build install
> >
> > - Hacking:
> >
> >   * meson.build: Mandatory for the project root and usually found under
> >                  each directory you want something to be built.
> > ```
>
> I'm not sure if this should be part of the commit message, personally I
> would prefer to have it as part of README or HACKING or something like
> that where it is visible even from tarball.
>
> Few more notes that I've noticed:
>
>     - There is a regression, with meson we no longer have generated RPM
>       spec files in tarball.

This one really slipped out of my mind at some point. :-/

>
>     - With autotools there were some configure options:
>         --enable-vala [default check]
>         --enable-coverage [default no]
>         --with-usb-ids-path [default (internal)]
>         --with-pci-ids-path [default (internal)]

Well, those options were only there due to a c&p from libosinfo, when
osinfo-db-tools was split out of the libosinfo.

>         --enable-werror [default git ? yes : no ]

--enable-werror is just a matter of using -werror with meson.

>
>     - I'm not sure what are the best practices, but basically all of the
>       projects using meson that I've check have the generic things like
>       dependencies, compiler flags and so on in the root meson.build
>       file.  All the other meson.build files handles only the
>       compilation or code generation, ... for the specific directory.
>

So, I've taken a look at gnome-boxes code before organizing mine and
also discussed this with Felipe Borges.
I guess this is a matter of personal choice and i've followed what
seemed to be the more "modular" approach.

> Otherwise looks good to me, but I've just started with meson myself so
> we should get some other reviews (yes, probably Daniel :)).

Thanks not only for the review but also for the discussions we had in
the office. :-)

>
> Pavel