This article describes one approach for using autoconf to generate configure scripts for projects that use mktclapp. The configure scripts that are generated using this approach have been tested to compile natively on Linux, Windows95 (Cygwin20), SunOS, and HPUX and to cross-compile from Linux to Windows95. The configure script also supports using a build directory that is completely independent of the source directory. The source code can even be on a read-only filesystem, such as a CD-ROM.
This information is provided as a public service, with the hope that it might be useful to someone. There is no warranty as to how well this system works. Nor is there any promise of support.
The image to the right gives an overview of how the scheme described in this article works. The developer must come up with two input files: configure.in and makemake.tcl.in. The first file, configure.in is the M4 script that autoconf uses to generate its configure shell script. There is a template configure.in file included with this article that should work in most applications with little or no modification. The makemake.tcl.in is a TCL script that will be used to generate a Makefile for the project. The configure script will make a few modifications to this TCL script before it runs, in order to customize it for the target platform. A template makemake.tcl.in is also included with this article.
After generating the configure.in file, the developer then runs GNU Autoconf version 1.13 to generate a configure shell script. The configure shell script becomes part of the source tree. The configure shell script is not considered a build product. It is placed under configuration management just like any other source file.
To build the project, the developer creates a new directory that is separate from the source tree. Suppose the source tree is rooted in a directory named src which is a peer of the build directory which is named bld. To build the project, the developer changes to the bld directory and types:
../src/configure
This command runs the configure script that autoconf generated. The configure script examines the system on which it is running, discovers an appropriate C compiler, compiler options, Tcl/Tk libraries, and BLT libraries, then generates a Makefile and a file named makemake.tcl based on makemake.tcl.in. All of these generated files are in the build directory. (Notice that the Makefile is built without a template Makefile.in. This is a bit unusual for autoconf, but it is part of the design. Read on...)
After the configure script is run, the developer types:
make
This command launches the make utility on the Makefile that the configure script generated. This Makefile is very simple. About all it does is run makemake.tcl to generate a new makefile called all.mk. The make program then calls itself recursively on the newly generated all.mk in order to build the project. Note that the project is build in the local directory, not the source directory. Note also that any old version of the make utility will do. GNU make is not required.
There are, of course, many ways to make use of autoconf. And most other ways are more conventional that the scheme described above. But this approach does have certain advantages.
The same source directory can be used to build for multiple targets.
By putting the source tree on an NFS- or SMB-mounted filesystem, lots of different computers can read the sources at the same time. And they can all compile off of the same source tree, putting there build products in separate directories. The separate builds can even take place at the same time.
The source tree can be on a read-only filesystem.
This allows you to compile directly from a source tree located on a CD-ROM, for example. There is no need to copy the source tree onto read-write media prior to the build.
The use of "tclsh" in the build process gives much more control to the developer.
A makefile is not a program. There are a lot of interesting things that a makefile will not do. For example, standard makefiles have no provisions for conditional compilation. (GNU make has this capability, but GNU make is not standard and is not installed on every system.) Running tclsh to generate the makefile allows the developer to radically change the build process depending on the characteristics of the target machine.
If you want to try using the build scheme described here, first get a copy of the configure.in template. You can find the template at:
http://www.hwaci.com/sw/mktclapp/configure.in
You will need to modify this file to suit your application. But the modifications are normally modest. First change the argument of the AC_INIT() macro to be the name of a file in your project's source tree. If your project does not use the BLT extension, then disable the tests for BLT by commenting them out. If your project uses some extensions other than BLT, you may have to add new test to the configure.in. Use the existing code as your guide.
The configure.in contains comments to help you understand how it works. You may also want to refer to the Autoconf manual for information on the Autoconf macros.
The next step is to generate a suitable makemake.tcl.in. You can begin with the template at:
http://www.hwaci.com/sw/mktclapp/makemake.tcl.in
The template is really a working makemake.tcl.in file for a specific project. The project is not Open-Source and so the source code is not available. But that is not important. The comments in the template file should give you plenty of guidance on how to adapt the template to your particular project. Remember, you are working with plain ordinary TCL code. The output of the script will become a makefile. Be creative.
The final step is to run autoconf version 1.13 or later to generate the configure script. You can obtain a copy of autoconf from lots of places on the net. Use a search engine to find one near you if you don't already have autoconf installed on your machine.
For additional information, read the template files.
It is important to emphasize that there are many different ways of building a project, and many different ways of using autoconf. You are welcomed to use the approach outlined here if it suits your needs. Hopefully you will find this information helpful. But the techniques described here will not work in every circumstance. You may have to change things. You may have to use a completely different build scheme.
If you fix bugs or make extensions to the template files described above, then patches sent to the author at drh@hwaci.com will be welcomed. Your patches will be gratefully acknowledged and added to the distribution. Reports of bugs without fixes, or requests for new features, may or may not be acknowledged.