I've copied libtool into my program's source tree to distribute it with the program. But when I run 'make distclean' libtool is deleted with the rest of the rest of the generated files. How do I stop that from happening?
I tried putting EXTRA_DIST = libtool in Makefile.am but that doesn't work.
Here is basically what my configure.ac looks like.
AC_PREREQ(2.53)
AC_INIT( [program], [0.16], [program] )
AC_CONFIG_SRCDIR([src/c/program.c])
AC_CONFIG_HEADER([config.h])
AC_CONFIG_AUX_DIR(build-aux)
AM_INIT_AUTOMAKE( [-Wall -Werror foreign] )
m4_include(ax_pkg_swig.m4)
# Checks for programs.
AC_PROG_CC
AC_PROG_LIBTOOL
AC_ENABLE_SHARED
AC_PROG_SWIG
# Checks for libraries.
# Checks for header files.
AC_HEADER_STDC
AC_CHECK_HEADERS([stdlib.h string.h unistd.h])
# Checks for typedefs, structures, and compiler characteristics.
AC_TYPE_SIZE_T
# Checks for library functions.
AC_REPLACE_FNMATCH
AC_FUNC_MALLOC
AC_FUNC_STAT
AC_CHECK_FUNCS([regcomp strdup strtoull])
AC_CONFIG_FILES([
Makefile
src/c/Makefile
src/perl/Makefile
src/verilog/Makefile
])
AC_OUTPUT
You're not supposed to copy libtool into your program's directory by hand. You run libtoolize in your bootstrap script, which handles this for you. I suppose it's doing more than just copying libtool for you, such as informing automake that it shouldn't delete the file. Here's a sample bootstrap script:
#!/bin/sh
aclocal -I config &&
libtoolize --force --copy &&
autoheader &&
automake --add-missing --copy --foreign &&
autoconf &&
./configure -C "$@"
This script is traditionally called either bootstrap or autogen.sh. These names aren't universal, just nearly so. Just a few days ago, I came across a project using bootstrap.sh, for example.
To a large degree the name of the script is a matter of fashion and style. It's not entirely superficial because part of the modern style is a move away from running configure at the end of the script. bootstrap is the newer name, so a script named that is less likely to run configure at the end. Chapter 8 of the Autobook implies that this is the case, too, but I've run across counterexamples. (That is, projects with an autogen.sh script that does not call configure, and projects with a bootstrap script that do.)
To my mind, the question of whether to include the configure step at the end come down to how typical your project's use cases are. If almost everyone needing to bootstrap your project's build tree will accept the standard configure flags defined in the bootstrap script, or maybe add one or two simple ones, it's fine to run configure automatically. It's best to make it a separate manual step if a lot of people will need to do heavy customization. An example is when a lot of your users are cross-compiling your project. The ways to ask configure to do this are well known, whereas someone would have to read your bootstrap script's code to figure out how to get the options passed through to the embedded configure command.
You will almost certainly have to customize this script to your project's needs. The most important thing to leave as-is is the order of operations. The Autotools are sensitive to that. You may have to change the flags given the commands; the -I config on the aclocal command isn't universal, for instance. You're even more likely to need to add steps to the process, either surrounding these common steps, or maybe even interleaved with them.
As for the autoreconf option, I have yet to become a fan. I find that its built-in assumptions break down on all of my projects, somehow. If your project is a bog-standard GNU-styled project, it may work for you.
By the way, the AC_PROG_LIBTOOL macro is obsolete. You should be using LT_INIT instead.