You might have noticed a slight visual change of this site. Well, I just pulled
the trigger and re-wrote this site’s CSS based on milligram in about an
hour. The sole reason for that was that the old CSS was an unmaintable, barely
responsive mess. I am not a CSS expert, so why not leverage one of the countless
minimal CSS frameworks and add a few customizations to get away from that
hip and modern low-contrast look?
With that came a few changes that made this site leaner and cleaner: I removed
the few Font Awesome icons thus avoiding one more stylesheet and loading of
a web font, changed the heading font from Lato to Roboto Condensed and removed the
Unica One font which was used only in the header bar.
All in all I am pretty happy with the change and the fresh look.
For the first time in a long time I felt happy about a piece of software: it’s
meson the build system. I wroteaboutmy
adventures with CMake but in the end I was never really happy with it. Be it its
arcane syntax, intransparent build process or lack of following standards common
in the nix world. I used it but grudgingly because I could not let my colleagues
be burdened with Autotools.
I read about meson about the time it was first announced but did not dare to
dive into it because of lack of maturity and long-term perspective. However,
learning that a lot of GNOME and systemd related software is moving from
Autootools to meson, I changed my mind and read the great manual in order to
convert some of our bigger C projects over from CMake. And what a joy it was!
First the build language: it’s clear, simple and deliberately not
Turing-complete. Unlike what a lot of folks imply when they hear that meson is
written in Python, the language itself is a separate domain specific language.
Many features of this language do not feel like an afterthought but very helpful
to describe build artifacts and build related information. For example string
and list processing such as
foo = ' '.join([bar, 'baz'])
feels a lot more robust than CMake’s
SET(foo "${bar} baz")
Having a real boolean type reduces the amount of guesswork in situations
with conditionals considerably. Having a Turing-incomplete language with an
object-oriented approach seems verbose, I had the reverse feeling that I was
writing less but more explicit code. A good thing in my opinion.
The best part on Linux is that meson does not try to depart too much from the
conventional ./configure && make && make install dance. meson works exactly
like configure except for the fact that it enforces out-of-source builds. In
this step, meson uses pkgconfig in a first class way to find a library’s
compile and link flags unlike CMake which for years suggested to use the
included modules. In the other direction, meson has first-class support for
pkgconfig file generation, with CMake having you to abuse configure_file()
and still get it wrong. There other tool-specific modules such as the gnome
module that let you finish your job in a few lines instead of constructing new
build targets with fragile command construction.
The configuration times for me with meson are almost ten times shorter than
CMake but this probably varies from project to project. The build times are
equally long if you opt-in to use CMake with Ninja,
the default build tool of meson. meson’s build output is a bit nicer because it
does not spam the console if there are no warnings or errors during the build.
For now I found only one thing that would have to let me go back to CMake once
in a while: meson requires Python 3.4 and newer. This is not the case on a few
machines I still have to work on, but time will let these phase out too.
As seen previously, installing a Flatpak is a relatively simple matter – and
with Flatpak bundles even a one-click story. Now, building a Flatpak and the
corresponding repository is a slightly different story that I want to tell you
with my adventure making a Flatpak for the latest 0.92 version of Inkscape.
I won’t go into detail about the build process itself which is described
just alright in the Flatpak developer documentation and a series of
blogposts by Flatpak developer Alexander Larsson. Unfortunately, it is not
100% complete and I had to resort to the manpages and existing Flatpak
descriptions of other projects to get going.
So first thing you want to do is skip the manual flatpak build process and
use the flatpak-builder tool right away. You want to make a package for a real
program and not some toy that does not have any external dependencies anyway,
right? So that’s what I did: I wrote a org.inkscape.Inkscape.json, listing each and
every dependency of Inkscape. Now here is a message to the dear runtime
providers: please provide a runtime for applications based on the C++ versions
of the GNOME libraries such as gtkmm. I wasted tons of brain matter and CPU
cycles hunting down and compiling1 all the correct library versions2.
Speaking of depdendency hell: the dependency “resolution” of flatpak-builder
is anything but smart. It caches build output but marks it dirty if any of the
previously declared modules is changed even if there is no direct dependency
between those two modules. Yay!
But besides those issues making the package, pushing the repo to a server and
installing the package from a remote is actually a pleasant ride …
If I find a cheap location to store the repo and bundle, I will let you know.
Update: You can find the resulting Flatpak bundle on the main
inkscape.org website.
Have I told you what a mess Boost is? C++: ✓. Custom build tool: ✓. SourceForge download: ✓. ↩
This is a follow-up to Simos post on how to install LibreOffice but using
Flatpak instead of Snap.
If you haven’t have the flatpak system installed yet you must install it first from
Alex Larsson’s PPA
