Name: libtool-cache - cache libtool commands for better compilation speed on Windows Version: 0.4 (2005-03-06) Author: Robert Ögren, or Contributions from: Tor Lillqvist Project home page: http://libtool-cache.sourceforge.net/ http://sourceforge.net/projects/libtool-cache/ License/copying: Copyright (C) 2005 Robert Ögren This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. See the file COPYING for the details. Please note: This version is still considered beta quality, and there are probably some bugs remaining. This is a tool for software developers, not for end-users. Also, don't report any compilation errors to maintainers of any open source project while this tool is in use. If you get a compilation error, first try clearing the cache files created by libtool-cache, make clean and make, and if that fails, re-run configure, make clean and make (without caching) to make sure that the problem is not caused by a bug in this tool first. Description: libtool-cache is a Perl script that caches the commands executed by GNU libtool to increase compilation speed on systems running Microsoft Windows and using Cygwin. It caches both compile and link commands. Caching compile commands gives nice speedups even the first run as the source and target file name are replaced by a generic placeholder before caching (the 2.6 branch of GTK+ requires only 9 different compile commands), while linking of libraries mostly give a speedup in subsequent runs (nice when doing a few edit-compile-test cycles). Linking of exe files gives some speedup even the first run if the exes are built from one source file with the same base name as the exe (like the GTK+ test programs or GIMP common plugins). Platform: Cygwin (*nix emulation on Windows), tested using Cygwin libtool 1.5.10, perl 5.8.6, bash 2.05b, autotools and gcc -mno-cygwin. It might work in other configurations with smaller or bigger fixes, I have not tested. MSYS is not tested at all, probably needs work. Using the MinGW compiler in a cygwin shell has higher probability of working but is not tested by me. It has successfully compiled the 2.6 branch of GTK+ and glib, atk 1.8, pango 1.8 and GIMP 2.2 as well as several other libraries. It should be possible to port this to other platforms without too much work, but the speed increase is probably not that big on platforms with native fork() support. Installation and usage: Step I - unpacking and preparing libtool-cache This step only needs to be done once, regardless of how many source trees you want to compile. 1. Extract the libtool-cache archive into a new directory (NOT in the source directory where you usually run configure) 2. Compile libtool-wrapper.c using Cygwin GCC: /usr/bin/gcc -o libtool-wrapper.exe libtool-wrapper.c 3. Open the libtoolcacheize script in a text editor and set the LTCINSTALLDIR variable to the absolute path to the libtool-cache directory from step 1. Also comment out the line above it that tells you to edit the script. 4. (optional) Open the libtool-cache.pl script in a text editor and change the options at the start of the script. Step II - applying libtool-cache to a source tree 1. Edit ltmain.sh and replace the last occurance of $(LTCC) with the path to Cygwin gcc (optional but see below). 2. Run autogen.sh (or similar) and configure (if autogen doesn't do it for you) 3. Run libtoolcacheize in the root of the source directory (where configure resides) 4. If you have used an older version of libtool-cache before, consider removing the .libtool-cache-* files in the root of the source directory. This might not be necessary, but if you experience compilation errors after upgrading, try it. 5. Run make and make install If you for some reason don't want to use libtoolcacheize, you can apply libtool-cache manually by following these steps: 1. Copy (or perhaps symlink) libtool-cache.pl and libtool-wrapper.exe to the root of the source directory (where configure.in resides) 2. Rename the generated libtool to libtool.orig 3. Copy libtool.sh to libtool Note that libtool-wrapper.c can easily be regenerated by letting the original libtool recompile any executable that needs a wrapper script (depends on uninstalled libraries) and just copying the generated .libs/lt-yourfile.c. Make sure it is compiled with Cygwin gcc (without -mno-cygwin)! It is possible to replace the wrapper exe file with a dummy file that does nothing, but then you may need to run some commands manually during make. The same goes for editing ltmain.sh If you are compiling a source tarball which already has configure generated, you might want to re-generate it using aclocal, autoconf, libtoolize, automake etc. (there might be an autogen script that does this for you) If the Makefiles have changed or configure is re-run, it is safest to clear the cache by remove the .libtool-cache-* files that are in the root of the source directory. You can try without clearing the cache, it usually works. After rerunning configure remember to run libtoolcacheize again. To achieve greater library installation speed, there is a setting, $skip_relink, at the start of libtool-cache.pl, which can be set to 1. This prevents libtool from relinking libraries when installing, which should not be necessary on the Windows platform. It is possible to disable caching of link commands for greater safety by changing some settings at the top of the libtool-cache.pl script. Known issues: - No locking of the cache files - this means don't use parallel make (or implement some locking yourself). - Not written with portability in mind. In particular, it uses / as path separator everywhere in the perl script. I don't know if MSYS can handle this. Also, it assumes that executable files end in .exe - The generated .la files are stripped of comments and blank lines but should otherwise be correct. If you compile libraries that are going to be released, consider disabling the caching of library linking to be on the safe side :) Future enhancements: - It would be nice to have a configure/install script that makes care of locating perl etc. - Improve the libtoolcacheize script so it can remove libtool-cache from a source directory - Some sort of cache validation? Or just clean it in libtoolcacheize? Reporting bugs and enhancement requests: The preferred way of reporting bugs and other requests is through the bug trackers at http://sourceforge.net/projects/libtool-cache/ The preferred way of submitting patches is to attach them to a bug report in the bug tracker. Please use diff -u style patches. If you found this tool useful or have enhanced it in some way, please write me an email and tell me! This will make me more motivated to continue working on the project. Have fun! Robert