libdaemon

Extending libdaemon

As Luca wrote, since I came home from the hospital I’ve been working quite a bit on LScube, in particular working on porting feng to use glib, which is a very interesting thing considering that it also allowed to reduce the dependencies (no more need for libgcrypt for instance, which was a problem to me since it didn’t use pkg-config and I find that a bit medieval nowadays).

One other thing that feng lacked was support for running as a daemon; as git-daemon shown recently, having proper support is much better than faking it through start-stop-daemon.

A proper support for running as a Unix daemon mean quite a few different things: proper logging to either stdout/stderr (when not running as daemon) or syslog (when running as daemon); pid file generation (a file, usually in /var/run, where the process ID of the running daemon is written); proper check for forking (so that the user is told if the daemon failed to start; check for if the daemon is running already if trying to execute it again on the same pid file (multiple instances, where allowed, should use multiple pid files); privilege dropping (you don’t want your daemons to run with root privileges, although the ones who provide network service might need those privileges at once to open privileged ports (below the 1024 boundary).

Implementing all these things can easily be a boring task considering that is almost the same for each daemon you might be writing (feng is not the only daemon in lscube). Luckily, someone already thought about this and started working on a solution: Lennart’s libdaemon, which he used for the Avahi daemon.

But as it happens, although libdaemon 0.12 (which is not even the latest version) already provides enough of the basics needed for feng, there are a few things that would require further wrapping around in the code of feng itself. This includes verbosity handling (you might not want to have information output on stdout/stderr; while with syslog you can easily configure your logging to reduce the output, on stdout/stderr you either implement verbosity or you get everything that is logged through the daemon_log() function), and privileges dropping.

The nice thing of working with good maintainers, though, is that they are open to suggestions and extensions, so thanks to Lennart availability, I started implementing those parts that I was lacking. Hopefully in a not-so-long time, there will be a new libdaemon release, which feng will use, that will provide all the needed functionalities.

I really like this approach since it allows to do the things right once and for all, upstream, without having to reinvent the wheel every time, especially considering that it’s not rare that, trying to reinvent the wheel, you get it -octarine- octagonal rather than round.

For those who would like to take a look at the work in progress of my extensions, you can find them on my git repository together with some autotools fixes and some patches for OpenSolaris compatibility.

2008-10-03 by English Technical 0

Improving autotools-based buildsystems

When I’m composing this blog post (a few days in advance of its publication), I just took a little forced break (because I’m missing some tool I can’t find) from hacking at autotools buildsystems.

In particular, I’m hacking at Lennart’s projects, mostly because I bumped libasyncns and noticed I could make the ebuild simpler if I changed a few things in there.

My target with this hacking session is to update the build systems to the latest version of autoconf (2.62), making use of some new features that can make it easier to handle the packages during ebuilds. I’ll be discussing here some of the changes because, first, I know Lennart won’t mind if I dissect his autotools-fu 😉 and second because it makes a nice “documentation” to show how to properly use autotools. If you want to check the changes I actually made, you can find all the repositories on my git server; Lennart’s projects are the ones under 0pointer directory.

The first feature I wanted to make use of was the presence of htmldir and docdir variables in the newer versions of autoconf (2.60 and later, if I recall correctly, certainly not 2.59). These two variables allow to declare in Makefile.am some files as text or HTML documentation, letting the user (or the ebuild) choose where to install those through --docdir and --htmldir options at ./configure. This is what allows me to skip dodoc and dohtml commands in the ebuild, as the build system will take care of installing everything.

Another useful feature of the newest versions is that the AC_HEADER_ASSERT macro now provides a --disable-assert option that can be used to disable the assert() function calls in software without having to add manually -DNDEBUG to your flags. Unfortunately this does not work perfectly as it expects that every source file includes config.h before any other include (the same requirement exists for AC_SYS_LARGEFILE for what it’s worth), but luckily Lennart’s projects are well written. Not all projects support disabling assert(), even though it’s supposed to be just a debug facility, a few projects don’t take extra measures ot make sure the code continue working fine and safe without them.

But there are more things I changed, to improve the readability, and not only of autotools. For instance I replaced the custom CFLAGS testing code with code that uses CC_CHECK_CFLAGS macro, which is available in the attributes.m4 macro file available on xine-lib’s repository (that macro file was originally developed by me for unieject and has been now copied over multiple projects.. I always try to keep it in sync). This makes it possible to cache the result of the tests on availability of CFLAGS, and allows for new compilers, supporting a GCC-like commandline, to work out of the box. Similarly, C99 language checks are replaced with AC_PROG_CC_C99 that takes care of discovering how the compiler supports C99.

More tied to Lennart’s code is the creation of a ZP_LYNX_DOC macro, in its own macro file, instead of adding on all the configure.ac files the code to handle --disable-lynx and the conditional. It is very useful to factor out these common pieces of code in their own macros, as it allows to just copy a file over when you need to fix them, or improve them, rather than having to cut copy and paste code, with the risk of making bigger mistakes.

And a suggestion for those of you who want to test an autotooled package out of git or another development repository: if it’s possible, use autoreconf -is instead of the standard autoreconf. This avoids copying over the macro and support files from /usr/share to your work directory, symlinking them instead. This reduces disk occupation and should also be faster to re-generate.

Unfortunately for now autoreconf does not seem to support extra extensions to autotools, like intltool or gtkdoc and you have thus to choose between executing them by hand, or using the bootstrap scripts that the developers provided (which is bad in ebuilds).

What autoreconf should be is a standardised bootstrapping script that takes care of using the right tools with the right options for one’s project. Unfortunately with the existence of tools like intltool and similar, that extend the basic autotools syntax, and don’t seem to be “accepted” by upstream, it starts to become overly useless. I suppose an option would be to create a generic, installable, autoreconf-syntax semi-compatible script that could be used instead of the various custom bootstrap and autogen scripts for the projects.

Anybody with some free time to start hacking at that? 🙂

2008-08-10 by English Technical 0

Please don’t build your examples by default

I’m in the middle of an emerge -e world I started to try getting as much glibc 2.8 failure have a bug already on Gentoo’s Bugzilla so that users hitting them don’t have to report them anew.

One thing I noticed during this rebuild is the amount of time spent with no good reason to build tests and examples.

I have the test feature disabled, I only enable it for the software I maintain, and I usually don’t have so much time to look at the test of all software. Still some packages, like dbus, hal, gtk, and so on, build their tests anyway. They don’t run them, but they build tests and example during the default make all call.

I talked with Lennart about that some time ago as also libdaemon does that. He pointed out to me that these examples are often a way for the developers to test that the code still links correctly, for instance, and thus should not be disabled by default during development. I agree it can be useful that way.

For this reason, I prepared a patch for libdaemon, that you can now find here, which I should have committed and I forgot about – I’ll see to do that soonish 😛 – which should make it possible to have the best of both options: developers still get their examples (and/or tests), while distributions can opt-out them.

For ebuilds, this means that the src_test function should do a make -C tests or make -C examples to build tests and examples, after such a patch is applied, to explicitly build the code that most users won’t need during standard run.

I know it’s just seconds, or minutes, of time to build the examples, but if you add all those up, you’re wasting lots of time. And we should always strive to optimise time usage, no?

Update: the conditional-examples patch was a dead link, so I now link directly to Lennart’s gitweb and the diff that he used; remember please that it works for examples, but tests might be slightly different.

Update (2017-04-29): That link is now dead so I removed the example, sorry.

2008-06-11 by English Technical 3