On 22/03/18 14:18, Eduardo Lima (Etrunko) wrote: > Here is the result of work in progress with replacing autotools with > Meson. I am sending the patches on the ML for easier visualization, but > if you want to try it, I would really recommend pulling from my gitlab > repositories, e.g.: > > $ git remote add etrunko https://gitlab.com/etrunko/spice-protocol > $ git remote add etrunko https://gitlab.com/etrunko/spice-common > $ git remote add etrunko https://gitlab.com/etrunko/spice-server > Woops, the correct URL for spice-server is $ git remote add etrunko https://gitlab.com/etrunko/spice Just a small heads up that I updated the branch fixing gitlab script. It will now run the tests, but as some of them fail, gitlab still reports failure as end result. https://gitlab.com/etrunko/spice/pipelines/19357237 > The development branch is named meson for all repositories. > > - Requirements: > > Python >= 3.5, as required by meson itself. > > The required Meson version is 0.45.0, which includes some interesting > features for the specific use case of subprojects, just like > spice-common. > > Recent distros are probably still lagging behind on the package version, > but there is an easy way to upgrade meson, by installing a new version > on your $HOME/.local directory with python 'pip'. > > $ pip3 install --upgrade --user meson > > After downloading the meson package, it is necessary to tell python > where to find it, via the PYTHONPATH environment variable. > > $ export PYTHONPATH='$HOME/.local/lib/python3.6/site-packages > > Then you are ready to go. > > - Basic workflow: > > 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 > > This is equivalent to the autogen/configure step in autotools. Meson > itself is only responsible for the configure phase, where it creates > the files that will be used by another lower level build-system, which > will actually do the build. The default one is ninja. > > $ ninja -C ./build > $ ninja -C ./build install > > Ninja defaults to parallel builds, and this can be changed with the -j > flag. > > $ ninja -j 10 -C ./build > > - Done: > > Protocol, common and server. > > - Missing: > > * Server: > - tests need to be adjusted so the executable can run in a path > other than the source files. > - version generation with git-version-gen if building from tarball. > IMHO, git-version-gen could be removed. > - Checks (syntax, etc), in maint.mk and cfg.mk, that are done whith > make distcheck. > > * Spice Gtk: > - Work in progress, but it will not interfere as much with other > projects, especially spice-common, as server did. When ready to be > used I will follow the same structure as others. > > - Hacking: > > Meson has a python-like syntax and it is very well documented. The key > files are: > > * meson.build: Mandatory for the project root and usually found under > each directory you want something to be built. > > * meson_options.txt: Options that can interfere with the result of the > build. > > For more details, please refer to the websites of each project: > > http://mesonbuild.com > http://ninja-build.org > > -- > Eduardo de Barros Lima (Etrunko) > Software Engineer - RedHat > etrunko@xxxxxxxxxx > > _______________________________________________ > Spice-devel mailing list > Spice-devel@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/spice-devel > -- Eduardo de Barros Lima (Etrunko) Software Engineer - RedHat etrunko@xxxxxxxxxx _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/spice-devel