|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.
James Dixon: Installing jstock with Slackware 14.1
Jan 19, 2016
James Dixon: Installing sbopkg with Slackware 14.1
Jan 16, 2016
James Dixon: Open Source Wealth Management
Jan 15, 2016
Hans Kwint: GNUifying Windows: Make the best of imposed Windows-use at work
Oct 23, 2015
Dr. Tony Young: Update to "How long is a piece of string?"
Oct 20, 2015
Russell Hollander: Chromebooks, Linux, and Lenovo
Sep 23, 2015
Scott Ruecker (Phoenix, U.S.) : Interview With Richard Kenner of AdaCore
Aug 29, 2014
penguinist: Better Than a Quad-Head Display: My Adventures with "4K" 2160p and Linux
Mar 31, 2014
Dr Tony Young: Replacing KDE4 with Xfce
Mar 07, 2014
Dr Tony Young: Removing/Disabling The Semantic Deskop in KDE4 Running on openSUSE 13.1 Part 2
Feb 18, 2014