return to OCLUG Web Site
A Django site.
December 16, 2012

Michael P. Soulier
But I Digress
» Getting started with autotools

So, I'm still reading O'Rielly's 21st Century C. I know, too many books on the go and I read slowly, and not often enough. I'm going through the section on GNU autotools, which I've never been a heavy user of, albiet I'm a heavy consumer of. I just don't spend much time distributing C/C++ across platforms.

I have a little C tool that I figured I'd try it on, a small replacement for GNU tree that I wrote a while back, and since tree isn't available on OS X, it seemed a good excuse to port it. Previously I just had a Makefile that I maintained, and it works fine, but it's a good excuse to learn how to use autotools for the future. I do have some libraries, and they're harder to port, which is where libtool comes in.

This build script outlines the process of using autotools for the first time. This script borrows very heavily from the book's author.


echo "Creating"
cat > <<EOF

echo "Running autoscan..."

echo "Creating"
sed -e 's/FULL-PACKAGE-NAME/twig/' \
    -e 's/VERSION/1.0/'   \
    -e 's|BUG-REPORT-ADDRESS||' \
    -e '10i\
        < configure.scan >

echo "Creating additional files..."

echo "Running autoreconf..."
autoreconf -iv

echo "Running configure..."

echo "Running make distcheck to package sources..."
make distcheck

At this point, it's not ready to ship, as the NEWS, README, AUTHORS and ChangeLog aren't populated yet. But it's close. The configure script works, and I could then build it on OS X using the expected.

./configure --prefix=/usr/local
make install

My next project to package is a shared library for work, so that will be more interesting. Still, if you're looking to use autotools for the first time for something simple, this should take the mystery out of kick-starting it. Sure, there's some magic like the AM_INIT_AUTOMAKE macro, and I've a ton to learn yet, but this worked on the first try, and the resulting tarball is good to push to SourceForge or elsewhere if you want to.

As I pick up more, I'll try to share it. I don't find autotools intuitive at all, but with some simple recipes I think I'll survive.

November 7, 2012

Michael P. Soulier
But I Digress
» 21st Century C

I saw a sale from O'Reilly Publishing tonight on an new ebook for 21st Century C. I have a good history with O'Reilly and C programming, so it caught my attention.

When I was in University, Practical C Programming taught me much more than any of my professors, and Unix System Programming for System VR4 taught me a great deal more about programming C on Unix/Linux. After reading those books, I became actually comfortable in working in C for all of my assignments, and other students kept coming to me for help until I had somehow become a local C expert. Amazing what a good investment in reading material will do, not to mention actually reading said material. Another friend in University taught me that. He told me not to ever begrudge the cost of a book that helps you get better at what you do. I've applied that lesson ever since.

I relied on O'Reilly for my first introduction to C++, with C++, the Core Language, which finally explained to me where some of my memory leaks were coming from, by explaining copy constructors and assignment operators. I turned to another book to finish most of my C++ education, but O'Reilly got me started.

Since University, with the wealth of information on the Internet, I haven't bought many C books, but I did pick up Advanced Unix Programming, second edition, on the recommendation of a coworker, and he did not lead me astray, the book is excellent. Mind you, I still haven't finished reading it. I seem to buy books faster than I read them these days.

Maybe one day I'll take a little vacation just to read. Anyway...

Looking at the new O'Reilly book, it looks like it has many practical ideas for someone living with C from day to day, and should also provide a nice introduction to the new C11 standard, just released in December of last year. Hopefully it'll sharpen my skills like previous O'Reilly books have. I'll try to post a full review once I've finished it...err...if I finish it.

I will stop buying faster than I can read. I will stop buying faster than I can read. Maybe if I keep repeating that, it'll sink in.

August 21, 2009

Bart Trojanowski
Bart's Blog
» prettier function tracing

This is a follow up to my pretty function tracing article. I base this work on the code presented there.

Some one asked me how to get the gcc -finstrument-functions feature working. If you don't know this flag will modify the entry and exit to/from each function to make a call out to a special set of functions used for tracing.

While I've read about this feature, I never actually tried it. So here is what I learned...

[Read More]

June 25, 2009

Bart Trojanowski
Bart's Blog
» portable printf

I was squashing some warnings in uzbl code:

    printf("set %s = %d\n", (char *)k, (int)*c->ptr);

Ignoring the fact that, at first glance, it's weird to cast a pointer to int (ptr is defined as void**), compiling this code on 64bit would warn you that you were casting a pointer to an int. That's because a pointer is 64bit and an int is 32bit.

[Read More]

March 23, 2009

Bart Trojanowski
Bart's Blog
» popen with stdin, stdout, and stderr

I've look around for an open source implementation of popen() that can handle redirection of stdin, stdout, and stderr of the program executed. I was unable to find one, so I wrote my own.

If you need to fork a helper process and maintain bidirectional communication wtih it, then you can use my popenRWE() (source: popenRWE.c.

Here is an example of how it might be used:

    int pipe[3];
    int pid;
    const char *const args[] = {

    pid = popenRWE(pipe, args[0], args);

    // write to pipe[0] - input to cat
    // read from pipe[1] - output from cat
    // read from pipe[2] - errors from cat

    pcloseRWE(pid, pipe);