"The good news about computers is that they do what you tell them to do. The bad news is that they do what you tell them to do."

-- unsure; often attributed without source to information philosopher Ted Nelson

Software development

Software development guidelines by Ken Gaillot

Portability

There are many variations among Unix-like operating systems for things like path names to standard commands, names of header files to declare certain functions, the type definition of certain functions' arguments and return values, and whether certain common C functions (like memcmp(3)) are defined at all. If these things are not taken into account, your package will only run on the operating system used to develop it.

Portable system calls

(TO DO: use high-level interfaces like readdir instead of accessing system structures like file directories directly; glib)

Portable file naming

(TO DO: directory separators; check TMPDIR env var first instead of "/tmp")

Programming with autoconf

Autoconf provides a powerful means of determining the operating system's capabilities.

To make use of autoconf, the developer should "#include <config.h>" near the top of each source code file. If you don't use automake, you'll have to edit the Makefile and add an -I option to the compiler flags to find config.h. Automake takes care of this automatically.

For each system-dependent feature you wish to use, you can define an appropriate macro in configure.in, and when the package is installed, configure will determine the system's capabilities and set an appropriate #define in config.h.

As just one example, if you want to use the "size_t" type in your package, which is not defined by all Unix-like operating systems, set the "AC_TYPE_SIZE_T" macro in configure.in, and configure will define size_t if the OS doesn't.

For details, see the autoconf documentation.


Security

(TO DO)

Tools