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

[Pavel Hrdina]

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.

    - 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)]
        --enable-werror [default git ? yes : no ]

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

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

Pavel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libosinfo/attachments/20190620/d45eff49/attachment.sig>