|Posted by tadelste on Jan 7, 2006 8:36 AM|
Systhread; By Jason (Jay) R Fink
Setting up software for distribution can be a daunting task. Most of the the time, a well written makefile does the trick. Sometimes a little more is needed - or even expected. The GNU autotools for setting up a software distribution can help iron out some of the problems a programmer might run into.
Using autotools for a very simple piece of software still requires
a few steps:
- Move the Makefile to Makefile.in
- Run autoscan
- Edit the
- Run autoconf
- make any final adjustments
The Example - etu
The Enlightenment Thumbnailing Utility or etu makes use of a simple
(but powerful) scaling API for jpeg images. Initially, etu was comprised
of very few files:
There are also some test images, however, they are not used for building
in any way.
- Makefile - to build and install it.
- README - a simple README file with news and credits.
- etu.c - the source file for the utility itself.
Move the Makefile
Makefile is relatively simple (as it is in the case
of etu) then it can just be moved to
Running autoscan without results in the following:
configure.scan etu.c Makefile README test-images/ test.jpg
autom4te: configure.ac: no such file or directory
autoscan: /usr/bin/autom4te failed with exit status: 1
One nice thing, however, it generates a
file which can be used as a starting point. First, the
configure.scan is copied to
configure.in File Contents
The file sets up the checks to be performed, most of these are self
# Process this file with autoconf to produce a configure script.
AC_INIT(FULL-PACKAGE-NAME, VERSION, BUG-REPORT-ADDRESS)
Anyone who has viewed the source code for etu knows there is already one
problem, there is no check for the
# Checks for programs.
# Checks for libraries.
# Checks for header files.
AC_CHECK_HEADERS([stddef.h stdlib.h string.h unistd.h])
# Checks for typedefs, structures, and compiler characteristics.
# Checks for library functions.
Epeg.h file. This can
be remedied by simply adding an entry to the
# Checks for header files section, under the
AC_CHECK_HEADERS([stddef.h stdlib.h string.h unistd.h Epeg.h])
Next it is time to run autoconf - those paying close attention may notice
there is an error coming:
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
configure: error: cannot find install-sh or install.sh in . ./.. ./../..
install.sh file isn't actually needed, the easiest way
around this is to create a placeholder (besides, it may be needed
at some point later).
echo "Do nothing - a placeholder for autofoo" >> install.sh
Now when autoconf runs, everything works. Note that the
header is checked for:
checking Epeg.h usability... yes
checking Epeg.h presence... yes
checking for Epeg.h... yes
At the point where
./configure works, it is time to test it
in a platform where it should fail. The distribution was copied
into a NetBSD system that does not even have X windows installed:
checking Epeg.h usability... no
checking Epeg.h presence... no
checking for Epeg.h... no
So there it is, it will not work on this system and a notice was put
GNU tools do like a few other files although they are not required. In
general it is nice (but not required) to add:
Again, none of the above listed files are required unless a particular
project needs them - but they are nice to have.
- A COPYING file with a copy of the license (unless this is noted in
the source code itself).
- README file with general information.
- AUTHORS file with the names and contact information of the authors.
- INSTALL file with basic instructions.
- TODO file with a any work that might need to be done (a good way
to attract other developers).
- ChangeLog file with a description of changes between versions.
Using autotools even on a basic program (such as etu which is about as basic
as it gets) can help to move a program from system to system without too
much fuss. This article only touched on how to set up a simple
autotools based distribution, hopefully in the future a more in depth
look will be done here, however, in the meantime please take a read of the
GNU Build manual for more details.
This article also appears at systhread. Special thanks to Jay Fink.
Return to the LXer Features
This topic does not have any threads posted yet!
You cannot post until you login.
ubuuser: The good and bad of Ubuntu 13.04 beta 2
Apr 15, 2013
Scott Ruecker (Phoenix, U.S.): LXer Weekly Roundup for 10-Mar-2013
Mar 11, 2013
Scott Ruecker (Phoenix, U.S.): LXer Weekly Roundup for 03-Mar-2013
Mar 03, 2013
: Ubuntu Touch Developer Preview released
Feb 21, 2013
Scott Ruecker (Phoenix, U.S.): LXer Weekly Roundup for 17-Feb-2013
Feb 18, 2013
Scott Ruecker (Phoenix, U.S.): LXer Weekly Roundup for 03-Feb-2013
Feb 04, 2013
Nick Black, SprezzOS Project Hacker-in-Charge: SprezzOS emerges, promising new-school tech with old-school gumption
Feb 02, 2013
Scott Ruecker (Phoenix, U.S.): LXer Weekly Roundup for 27-Jan-2013
Jan 28, 2013
Scott Ruecker (Phoenix, U.S.): LXer Weekly Roundup for 20-Jan-2013
Jan 21, 2013
ubuuser: Ubuntu releasing smartphone OS has better chance than other platforms
Jan 09, 2013