On Thu, Jun 20, 2019 at 6:42 PM Pavel Hrdina <phrdina@xxxxxxxxxx> 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 _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
