The ancient practice of putting various monsters in unexplored regions of maps and the phrase based on that, “Here be dragons“, applies still to programming.  Personally, I’ve always had a dragon the size of a moon (or battlestation, if one prefers) on my own mental map in the area of build systems.  Hopefully, this should be a series, with several tutorials succeeding this brief summary of available options.

What is a Build System?

Just a quick introduction for those who are uninitiated into these rgb(0,0,0) arts.  A build system offers a relatively easy way to automate building and packaging of a software system.  While something as simple as a one-line shell script could supposedly be written for smaller projects, this has several problems.  Firstly, it would tend to redundantly and naively recompile objects that have already been built and have not been changed.  Secondly, this has no portability system; that is, it has no way to analyze the host system and find the appropriate utilities and libraries on differing platforms.  There are more reasons, of course, but these are the crux of the matter.

Current Build Systems

Make

Make is one of the oldest build systems, having its first release in 1977 at Bell Labs.  It is extremely simple, but pays the price; it has no configuration system, nor any automatic dependency analysis.  This makes it a decent choice for smallish projects with any advanced portability needs, but most likely you’re better served by a more powerful tool.  However, it should be noted that various projects such as Autoconf (see below) serve to expand this utility.

Autoconf

Autoconf and Automake together form a framework for generating Make scripts.  Autoconf provides the portability configuration system, while Automake will automatically analyze your program structure to determine the order that things need to be rebuilt in.  Unfortunately, on some level, this is merely lipstick on a pig (which is an idiom I used to be able to use without shifting my eyes), and due to the obscure language (m4) used to write Autoconf scripts, this is both a finicky and difficult option to use.  Configuration is slow, and is extremely awkward if you wish to target Microsoft Windows.  Last but not least, it is legendary for being extremely difficult to learn.  It is, however, the most common build system on the Free Desktop.

SCons

I’ll get my bias off of my chest now: SCons is my current favorite build system.  The scripts are written in Python, so you have a very powerful programming language to work within.  The API is a bit less than ideal in some ways, but is still quite usable.  Compilation is fast and portable, as well as being in one step (as opposed to the two-step compilation as used in Autoconf).  The GNOME project is currently considering switching to it from Autoconf.

Waf

Waf is a descendent of SCons, and thus shares the power of Python.  However, it is expanded in several ways: the API is retooled and is more intuitive in design in some ways; the configuration stage has been spawned into its own step; and compilation is quite pretty.  Despite all of this, it does suffer from a lot of API irregularities and absolutely intolerable documentation.  It is also important to note that Waf is unique in the build systems that I’m aware of in that the preferred way to use it is to actually ship it with the application itself instead of using a system-wide installation

CMake

CMake is the build system for KDE 4, and is a very nice and simple build system for projects of any size.  However, this clean and simple design is detracted from by the simplistic (though not to the Make extreme by any means) language used to develop for it.  If you can get past this weakness, however, very nice things lie inside, such as an integrated unit testing framework.  It is worth noting that rather than being a base build system, it instead generates files for the native build system (Microsoft Visual C++ on Windows, Makefiles or KDevelop on *NIX, etc.)

Others

This is where the real dragons are; the previous build systems I have at least some experience with, but these are build systems I have only heard of.  Despite this, I would feel remiss in my duties to you the reader if I did not at least mention some of the lesser-used options.

• Apache Ant is a build system is aimed at Java projects, and has its project files written in XML.
• Perforce Jam appears to be a C/C++ build system with a syntax reminiscent of Make, but with portability features, control structures, and automatic dependency ordering.
• QMake is a Makefile generator not unlike Autoconf, only with a much easier-to-learn syntax.  It is part of the QT toolkit.

This list is by no means complete.  If you have a favorite build system, please do mention it in the comments.

Introduction

“Listen. Easy now,” said the old man gently. “I know, I know. You’re afraid of making mistakes. Don’t be. Mistakes can be profited by. Man, when I was younger I shoved my ignorance in people’s faces. They beat me with sticks. By the time I was forty my blunt instruments had been honed to a fine cutting point for me. If you hide your ignorance, no one will hit you and you’ll never learn. [...]”

–Fahrenheit 451

Newbie programmers, when set to complete task, will often complete the task in the worst way possible. Of course, most programmers graduate beyond newbies. This post will detail some questions that newbies can ask in order to build better programs.

The below questions are things that all newbie programmers should be asking themselves so they can produce good programs. The questions can also be used as a very simple litmus test to see whether a programmer is a completely lost newbie or not. The Five Essential Phone-Screen Questions has a set of questions that help find good programmers.

<insert image here>

Photo credit: Flickr user anomalous4

When coming up with ideas for solutions

1) What patterns or algorithms can help me solve the problem?

Computers work well with numbers, and numbers are full of patterns and sequences. A simple example of a sequence is the Fibonacci sequence, where every number is the sum of the previous two numbers (1, 1, 2, 3, 5, 8, 13…).

A simple and useful algorithm is the Sieve of Eratosthenes, which is used to create lists of prime numbers.

2) Has somebody else already solved this problem or a similar problem?

Google called; they said they have the answer to your problem.

For those that can handle looking at the possibly messy code of others, looking online for open source code that can partly, mostly, or completely fill a need is a good idea.

A somewhat recent example is that I was looking for an open source Digg clone in PHP to make slight modifications to, and managed to find Pligg. Unfortunately, Pligg didn’t manage to fit my needs, but I managed to find PHPDug, which I like better.

3) What are potential issues I could run into when solving this problem?

It is important to think ahead about what issues could be faced when solving a problem.

For an important website, the power of the hardware, the power of the software, and the precautions taken for data loss and downtime, and more should be considered.

When looking at possible solutions

The first group of questions are things that newbie, or n00b, programmers should ask themselves when looking at a source code or a way to solve a problem.

1) Is this method fast as it can be?

Writing fast programs is a very important thing. Too many people are not patient enough for slow programs, and writing programs that can easily be made faster is not going to make users happy.

2) Is this method secure?

I sometimes wonder if it would be more beneficial to beginning developers Baller shouted “Security!” instead of “Developers!”.

Some common, but dangerous security mistakes that n00bs make are:

1) not escaping user input

2) not using file permissions properly

Chmodding everything is 777 is bad. Very bad.

3) using improper encryption to store things

3) Is there a simpler way of solving this problem?

If a person has two solutions to solve a problem, that person should always choose the simpler solution. The more complexity there is in a system, the more difficult it is to use and maintain that system.

4) Is this method scalable?

Creating software that works perfectly, with the exception it not being scalable at all, is setting up the programmer(s) for some major headaches down the road. A classic example is Twitter’s severe instability a few months ago.

Final notes

All programmers ought to subscribe to Coding Horror, a blog with far more useful content than you’ll ever find in this waste of disk space.

Also remember to ask questions on mailing lists, forums,  and so forth, but only after several hours of experimenting with Google keywords.

I had cause of late to convert an integer into a string in C.  My research indicated that there was no standardized function to do this, and thus the most portable thing to do was to write my own algorithm.  After fiddling with numbers and masks and such things, I came up with the following core algorithm:

#define CONVERT_DIGIT(mask, n, offset)    (( n/mask - ( n/(mask*10))*10) + offset )

This algorithm may not be as efficient as it could be, but I’m fairly happy with it given that normally I dodge anything with even a distant correlation to mathematics as if it were the plague.  mask is a power of your number system base b; most of the time, this is going to be a power of 10.  n is the number you want to convert.  offset is used to offset the resulting integer to an ASCII equivalent; this could actually be hard-coded as 48.

Given that the number of digits in n is L, you need to initialize mask to b^L-1.  Then run a loop that for each digit in n runs CONVERT_DIGIT( mask, n, 48) and then divides mask by b for the next iteration.

Caveats

While the algorithm itself should be O(L), the actual output is going to have some worthless zeros at the start for most values of n that may have to be stripped.  In addition, I’m not going to explain how to create a string in C, or how to implement this in other languages.  You’re on your own there.

Also note that while the premise should be solid and I haven’t seen a situation where it fails, I disavow all responsibility for algorithmic failures and weaknesses.

EDIT: Daniel Bruce informed me that the function sprintf() would do the job just as well, only should also work for floating point numbers and is more flexible.  I wish I had known about that before I had spent the time to write this algorithm.