Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Back: 24.2 Overview of the Two Approaches
Forward: 24.4 Example: The Full Pull
 
FastBack: 24.4 Example: The Full Pull
Up: Migrating Existing Packages
FastForward: Integration with Cygnus Cygwin
Top: Autoconf, Automake, and Libtool
Contents: Table of Contents
Index: Index
About: About this document

24.3 Example: Quick And Dirty

As part of the libgcj project (55), I had to incorporate the zip program into our source tree. Since this particular program is only used in one part of the build, and since this program was already fairly portable, I decided to take a quick-and-dirty approach to autoconfiscation.

First I read through the `README' and `install.doc' files to see how zip is ordinarily built. From there I learned that zip came with a `Makefile' used to build all Unix ports (and, for the initial autoconfiscation, Unix was all I was interested in), so I read that. This file indicated that zip had few configurability options.

Running ifnames on the sources, both Unix and generic, confirmed that the zip sources were mostly self-configuring, using system-specific `#defines'---a practice which we recommend against; however for a quicky-and-dirty port it is not worth cleaning up:

 
$ ifnames *.[ch] unix/*.[ch] | grep ^__ | head
__386BSD__ unix/unix.c
__CYGWIN32__ unix/osdep.h
__CYGWIN__ unix/osdep.h
__DATE__ unix/unix.c zipcloak.c zipnote.c zipsplit.c
__DEBUG_ALLOC__ zip.c
__ELF__ unix/unix.c
__EMX__ fileio.c ttyio.h util.c zip.c
__FreeBSD__ unix/unix.c
__G ttyio.h
__GNUC__ unix/unix.c zipcloak.c zipnote.c zipsplit.c

Based on this information I wrote my initial `configure.in', which is the one still in use today:

 
AC_INIT(ziperr.h)
AM_INIT_AUTOMAKE(zip, 2.1)
AM_MAINTAINER_MODE

AC_PROG_CC

AC_HEADER_DIRENT
AC_DEFINE(UNIX)

AC_LINK_FILES(unix/unix.c, unix.c)

AC_OUTPUT(Makefile)

The one mysterious part of this `configure.in' is the define of the `UNIX' preprocessor macro. This define came directly from zip's `unix/Makefile' file; zip uses this define to enable certain Unix-specific pieces of code.

In this particular situation, I lucked out. zip was unusually easy to autoconficate. Typically more actual checks are required in `configure.in', and more than a single iteration is required to get a workable configuration system.

From `unix/Makefile' I also learned which files were expected to be built in order to produce the zip executable. This information let me write my `Makefile.am':

 
## Process this file with automake to create Makefile.in.

## NOTE: this file doesn't really try to be complete.  In particular
## `make dist' won't work at all.  We're just aiming to get the
## program built.  We also don't bother trying to assemble code, or
## anything like that.

AUTOMAKE_OPTIONS = no-dependencies

INCLUDES = -I$(srcdir)/unix

bin_PROGRAMS = zip

zip_SOURCES = zip.c zipfile.c zipup.c fileio.c util.c globals.c \
    crypt.c ttyio.c unix.c crc32.c crctab.c deflate.c trees.c bits.c

## This isn't really correct, but we don't care.
$(zip_OBJECTS) : zip.h ziperr.h tailor.h unix/osdep.h crypt.h \
		revision.h ttyio.h unix/zipup.h

This file provides a good look at some of the tradeoffs involved. In my case, I didn't care about full correctness of the resulting `Makefile.am' -- I wasn't planning to maintain the project, I just wanted it to build in my particular set of environments.

So, I sacrificed `dist' capability to make my work easier. Also, I decided to disable dependency tracking and instead make all the resulting object files depend on all the headers in the project. This approach is inefficient, but in my situation perfectly reasonable, as I wasn't planning to do any actual development on this package -- I was simply looking to make it build so that it could be used to build the parts of the package I was actually hacking.


This document was generated by Gary V. Vaughan on February, 8 2006 using texi2html

 
 
  Published under the terms of the Open Publication License Design by Interspire