Meson ♥ xmlrpc-c

xmlrpc-c is a lightweight RPC library based on XML and HTTP. For quite some time it’s outdated in Fedora (currently we have 1.32.5 which is older than stable/1.43.06 and even older than super-stable/1.39.11) so I started taking a look why.

Enrico Scholz, previous maintainer of xmlrpc in Fedora, did porting to CMake in 2007 and was supporting it until 2013 and even tried to get it in upstream, but upstream developer didn’t even reply (probably there was some communication, but not in public place). So version of xmlrpc-c we have in Fedora uses this patch-set. Because he gave up on maintaining cmake port and was not anymore interested in maintaining this package it’s oudated and not maintained.

Why not just drop this patch and use upstream’s buildsys? “Current buildsystem is broken and nearly unfixable except for the upstream author.” says Enrico and I tend to agree with him. It’s one of worst buildsystems I have ever seen (it’s common among scientists).

I started rebasing cmake port, but after 15 mins I gave up checking what each macro does there. It’s way better that original one, but cmake doesn’t really make your life easier, so I stopped wasting time and started my own meson port. It took me quite a while to make working meson port, most of the time I spent trying to understand how this make-ish thing generates particular library or even which libraries it generates. So, here it is: https://github.com/ignatenkobrain/xmlrpc-c/.

What did I achieve?

  • Cross-compilation for free.
  • Support for all OS out of the box (this is a bit lie since I tested only on linux, but it’s fairly simple to adapt for others). In original build-sys to build on windows you have to manually change some configs, run some different scripts and etc.
  • Maintainable build-sys code (1k of human-readable code vs 5k of function-over-function-with-shell-and-make).
  • Faster compiling. I can’t say that original build-sys is slow (actually it’s very fast since it doesn’t use libtool and all other automake stuff), but with meson I got it ~2 times faster.

What I didn’t achieve (yet?)

  • Building tests, examples, tools (in my TODO list since it’s required for my update in Fedora).
  • Building wininet-client and libwww-client (I’ve never heard about these before and not sure if anyone uses them, so it’s not in my TODO list at this moment).
  • Push changes upstream (once I finish complete porting, I will try to get it upstream).

Funny (actually, no) thing I found in lib/expat/xmltok/Makefile:

# I can't figure out what XML_BYTE_ORDER is, but it doesn't look like the
# code has ever defined it.  That means it's treated like 0 in #if.  Since
# we started using the Gcc -Wundef option, that generates a warning, so
# se set it explicitly to 0 here.

CFLAGS_LOCAL = -DXML_BYTE_ORDER=0

I hope that upstream developer (Bryan Henderson) can make opposite of title so that not only Meson will ♥ xmlrpc-c, but also in opposite way ;). This will make people (package maintainers in first place) happy.

A bit more technical information…
Continue reading →

GUADEC presentation preview: compiling GNOME apps with the Meson build system

If you talk with software developers, sooner or later the topic drifts to tools. The most obvious one is the editor. People really love their editors and are happy to talk about the wonderful features they have and how they increase productivity. The second tool is the compiler, which also receive a lot of praise. The compilers we have today are massively better, faster and more powerful than ones from just 10 years ago. And then there’s the build systems, which are, well…

Sort of tolerated. Maybe. Ish.

The time has come to change that. Meson is a new build system that has been designed from the ground up for one purpose: to increase programmer productivity. The basic tenet is that every second spent writing build definitions is a second wasted, because that time and energy could instead have been spent on code. Every second spent waiting for the build system to do its work is likewise wasted. To demonstrate how Meson tackles this issue, here’s the full definition for building an executable with an external dependency:

project('sampleproject', 'c')
glib = dependency('glib-2.0')
executable('prog', 'prog.c', dependencies : glib)

This is all the developer needs to write. The build system takes care of the grunt work such as debug flags, cross compilation, dependency tracking and so on.

In addition to general features, Meson also has special support for tools used in GNOME development. These include GResources, GObject introspection and the like. This simplicity does not come at the expense of power, as compile times with Meson can be an order of magnitude less than with the Leading Brand build system.

If this has piqued your interest then do come to GUADEC presentation on Sunday, or, if you can’t wait that long, learn about the project yourself at mesonbuild.com.

See you in a few weeks,
Jussi

Meson and 3rd party dependencies. Wrap DB is here

In previous post I showed how to correctly use 3rd party dependencies. While I wrote that post I realized that making we need to do many things: create wrap file, create meson.build file, get checksums and upload archive with meson.build file to any http/ftp server. So we started thinking how to make it more easy for developers who just want to use dependency.

We discussed it and created web application which taking a care about making project.wrap and archive with meson.build available to developers – Wrap DB. It’s creating something like tags when pull request are merged in github. Let’s look at example.

Example project

Suppose you have a project that depends on the zlib compression library. First you go to http://wrapdb.mesonbuild.com and find the list of provided projects. After a few clicks you’ll get to the actual build definition, which can be found here: http://wrapdb.mesonbuild.com/v1/projects/zlib/1.2.8/4/get_wrap

Then you just add the contents of that page to the subprojects directory called zlib.wrap. The second step is to declare in your main build definition that you wish to use the subproject. That is all you need to do.

We feel that this is a great step in reducing dependency problems that plaque native code development. We hope you do too. Enjoy!

Common questions about Wrap

Q: Isn’t this just Go get or Rust cargo but for C and C++?
A: Yes. But our aim is to provide this experience for projects that do not support it natively.

Q: How can I contribute?
A: The simplest thing is to just use the service and give us your feedback. If you want to do more, we recommend creating your own wraps and submitting them to the database. The process is extremely simple and fully documented in wiki.

Q: Isn’t it unsafe to download and execute random source packages?
A: Wrap definition files are plain text so they are easy to audit. All downloaded files are checksum verified so you know that you are not man-in-the-middled.

Q: How is this different from existing dependency systems (biicode etc)?
A: To our knowledge this is the first system of its kind that combines the following features:

  • based on source code rather than prebuilt binaries
  • build system having a native concept of subproject embedding
  • multiplatform
  • fully open source and community-driven, no CLAs

Q: What about subprojects that themselves use subprojects?
A: This is fully supported of course. If you have two subprojects that use a common subsubproject, Meson will automatically detect this and do the right thing.

Q: What if I’m too lazy to search projects through the web ui?
A: We are working on a client that allows you to search and add subprojects directly from the command line.

Q: Can I run an internal version of the server for mirroring and keeping my internal projects?
A: Sure, the code is available. You might not even need the server, though, because hosting wrap files only requires putting a few files on an intranet server. Wrap also supports using Git checkouts as subprojects.

P.S. Original post (doesn’t have my thoughts and histories) is in maillist.

P.P.S. Web interface for Wrap DB is not good, we will make it nicer in the near future ;)

Meson and 3rd party dependencies. Only one correct way

Intro

As you know, many projects bundling libs (including source code of 3rd party libs). For example, SuperTuxKart bundles angelscript, bullet, enet, glew, irrlicht, jpeglib, libpng, wiiuse, zlib. All of this libs package in my favorite distro Fedora.

As Fedora maintainer I need to check what changed in bundled libs code, if nothing – write patch to use system lib, if few changes – write patch to use system lib and report bug against this lib in Fedora, if big changes – try to understand what changed, why it’s not in upstream, create FPC ticket and they will accept bundle – use bundle. If all devs will allow to use system libs – this will be great (0 A.D. and Xonotic does this). Yes, this is also cross-platform games.

In CMake I need to write custom FindSomething.cmake and fix some things in CMakeLists.txt. Providing switch between system and bundled sources is not easy. For example, in stuntrally to unbundle ~ 50% of libs I should Showing 49 changed files with 238 additions and 108 deletions. I hate it.

In Autotools I never tried to do this, I think I will kill myself if will try.

With Meson it’s really simple. Meson is designed to be simple for developers, maintainers and fast. Hi to m4 and that black magic.

I don’t want to write more here, please read manual at official meson wiki. Much better to see real example.

Example

If we don’t have library in system (I renamed libenet to libent to not delete enet from my system):
Meson wrap bundled
If we have library in system:
Meson wrap system

Feedback

Please do not hesitate to contact us via IRC (#mesonbuild on freenode) or send patches/issues via GitHub (https://github.com/jpakkane/meson)

P.S. When I wrote this example I found some missing functionality and minor bugs and sent patches[1][2]. If you want to try this example – you need apply those patches.

SuperTuxKart 0.9 landed in Fedora

As you probably noticed that SuperTuxKart 0.9 released ~ 1 month ago. I tried to build it in the same day, but build failed on ARM architecture. I looked at build logs and found that they again added another bundled library – angelscript. I didn’t have time to fix it, but I got some free days in this week. I added new package with angelscript in Fedora and built new version of supertuxkart today for rawhide and will do the same for F22 at next week.
SuperTuxKart 0.9

If you are interested – please read more long story..
Continue reading →

css.php