|  24.3 Example: Quick And Dirty 
As part of the libgcjproject (55), I had to incorporate thezipprogram 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 zipis ordinarily built.  From there I learned thatzipcame 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 thatziphad few
configurability options. 
Running ifnameson the sources, both Unix and generic, confirmed
that thezipsources 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;zipuses this define to
enable certain Unix-specific pieces of code. 
In this particular situation, I lucked out.  zipwas 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 zipexecutable.  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.
 
 |