Autoperl - an Autoconf/Automake build system for Perl applications
./autoperl --init
./autoperl
./configure
make {dist,clean,install}
Autoperl is a build system modelled after GNU Autoconf and Automake. The target audience is application developers; if you are writing a library in Perl, use Ext::MakeMaker instead.
The configure script has the ability to: - Check for missing or broken library dependencies - Check for required system binaries in the user's path - Define an alternate installation prefix or custom install path using DESTDIR - Enable or disable certain application-specific features at build time
The generated Makefile has the ability to: - Build a source tarball via the 'make dist' target - Install the application via the 'make install' target - Remove temporary files via the 'make clean' target
Application developers shouldn't have to write a build system from scratch for each project. Autoperl takes care of the minute details and lets you concentrate on the writing the application.
There are three basic steps to autoperlizing your Perl application:
1. Generate an initial configure.in file by executing 'autoperl --init'
2. Create a file called Makefile.am using Automake's syntax
3. Run 'autoperl' to generate a configure script
The first step, 'autoperl --init', is similar to running GNU Autoconf's autoscan utility. It creates a basic configure.in file for later use by Autoperl. It should not be necessary to edit the file by hand.
The second step uses Automake's syntax to define the names of source code files as well as the executables they are supposed to create.
The third step is the same thing as running 'autoconf' and 'automake'; the autoperl executable parses configure.in and Makefile.am to produce `configure' and `Makefile.in'.
Autoperl helps you write portable Perl applications.
The number one portability issue that application developers are likely to encounter is the lack of library dependencies on certain platforms. A complex Perl application may depend on several dozen libraries, none of which are guaranteed to be installed on any given system. Sometimes, a library may be installed but be too old or lack the functions that your application needs. Autoperl tests for missing or broken library dependencies.
Another portability problem is the lack of standardization of installation prefixes. For example, the BSD operating systems prefer installing packages into /usr/local, while most (but not all!) GNU/Linux systems install packages into /usr. Apple Macintosh OS X installs things into even crazier places (or even saner places, depending on your point of view).
Autoperl is a very flexible build system.
When a distributor wishes to generate a native binary package, she runs a packaging tool (RPM, DEB, pkg_create, etc.). During that package build process, the packaging tool needs to install the entire package under a temporary directory. The makefile that Autoperl generates allows you to relocate the entire installation to any directory by passing an environment variable DESTDIR to 'make install'.
It can be useful to build a complex application with one or more features disabled, or with experimental features enabled. Autoperl allows you to define custom arguments to ./configure to turn any feature on or off prior to installing your application. This approach eliminates the need for a configuration option in your application's configuration file.
Autoperl allows the user to designate what directories the package should be installed. When running `configure', the options below can be given (prepended with '--'), e.g. `--prefix=/usr'
DO NOT confuse `prefix' with `destdir' -- destdir is used to relocate the entire package to a subdirectory. See the section VARIABLES for information about the `destdir' variable.
The generated Makefile has the ability to: - Build a source tarball via the 'make dist' target - Install the application via the 'make install' target - Remove temporary files via the 'make clean' target
installing the Man pages for this package. The default is `$(datadir)/man'.
Not all of the GNU installation directories have been implemented; those omitted are
Autoperl makes no such distinction. Use `prefix' instead.
Autoperl does not distinguish between shared and local; use `statedir' instead.
For more information, see the GNU Coding Standards, section 7.2.4.
Autoperl uses Autoperl as it's build system (for obvious reasons). For a complete example of how to use Autoperl, see the Autoperl source code distribution itself. There are files called 'configure.in' and 'Makefile.am' that demonstrates the basic functionality.
perl(1), GNU Autoconf (http://www.gnu.org/software/autoconf/), GNU Automake (http://www.gnu.org/software/automake).
The GNU configure and build system http://www.airs.com/ian/configure/configure_toc.html
The web site for Autoperl is http://heily.com/mark/projects/autoperl
The GNU Coding Standards:7.2.4 Variables for Installation Directories
Autoperl has not (yet) been ported to the Win32 platform.
Autoperl cannot check for libraries that are use()'d from within an eval() block. You must manually specify the library in these cases.
Perl does not have a preprocessor, so you cannot prevent certain blocks of code from being compiled. This makes the notion of an 'optional library' difficult to implement if the library exports symbols into your application. It's best to use fully qualified symbols (e.g. OptionalLibrary::Foo instead of just Foo) if you want true 'optional libraries'.
Mark Heily, <devel@heily.com
Copyright (C)2003,2004,2005 by Mark Heily
This library is free software; you can redistribute it and/or modify it under the same terms as Perl itself.