execline is a very light, non-interactive scripting language, which is similar to a shell. Simple shell scripts can be easily rewritten in the execline language, improving performance and memory usage. execline was designed for use in embedded systems, but works on most Unix flavors.
ucspi-ipc implements D. J. Bernstein's UCSPI protocol in the Unix domain, making it trivial to set up clients or servers on Unix sockets. ucspi- ipc comes with utilities using credential passing on Unix sockets, which are designed to act like a fine-grained and efficient sudo without the need for setuid programs.
skalibs is a set of general-purpose, low-level C libraries, all in the public domain. It can replace or hide the standard C library to some extent. It is designed to allow building of small static binaries. It is used in building all skarnet.org software, including execline and s6.
s6-portable-utils is a set of tiny general Unix utilities, often performing well-known tasks such as cut and grep, but optimized for simplicity and small size. They were designed for embedded systems and other constrained environments, but work everywhere. Other sets of small utilities are usually system-specific; for instance, the (otherwise excellent) BusyBox project only works on Linux.
s6-dns is a small, efficient, complete, and IPv6-ready DNS client library, with synchronous as well as asynchronous APIs. It is designed to replace libresolv in projects that need to perform DNS resolution. It also comes with small command-line utilities to make common and not so common DNS queries.
s6-networking is a collection of small Unix tools designed to help networking. It includes clock synchronization, Unix and TCP super-servers, Unix and TCP access control, and other miscellaneous utilities. It is particularly suited for management of clients and servers on embedded devices, but works just as well on larger systems.
Re: Comments and alternatives
> The only thing auto* tools have good is that they work.
Not even. I am a
diet libc (http://www.fefe.de/dietlibc/) user, and I find it very difficult to link autotools-using programs against the diet libc. Why? Because the configure scripts detect that my system is Linux, and immediately assume that I'm using the glibc. Did I hear "open-mindedness" ?
So, as far as portability is concerned, autotools are a failure - I can't even make them work on my i386-Linux.
> Personally, I won't bother. I distribute
> my programs with a
> Makefile. Yes, it is not portable. But
> any developer can fix it in
> 20 seconds if it does not compile.
I think this is the way of wisdom.
Personally, I have developed my own set of libraries hiding non-portabilities
(skalibs (http://www.skarnet.org/software/skalibs/)), and build my software on top of it. Any portability problem is centralized in skalibs, and the build-time tests are understandable. I have no need for autotools, and I believe that no one has, either.