guys-

let's talk.

if( you know about autoconf, automake and libtool) 
   goto QUESTION:

autoconf uses the file configure.in to create the configure script.  
configure.in just contains some a list of macro tests you want added to 
./configure.  autoconf parses this file and creates a single bourne shell 
script (#!/bin/sh). 

the "configure" script created makefiles by reading a "Makefile.in" file 
and then outputing the "Makefile".   this "Makefile.in" is created by 
automake.

automake takes a Makefile.am and outputs a Makefile.in file.

QUESTION:

should i remove all the autoconf, automake, libtool derived files  and 
require that we run...

# aclocal
# autoheader
# automake
# autoconf

before we run

# ./configure

on the CVS source?????

if we do this, we must make sure we are all using the same version of 
autoconf , automake, and libtool. 

advantage: CVS is not cluttered with derived files and every checkin 
doesn't require updating these derived files.

disadvantage: if we are using different versions of the auto* tools then 
we'll be assuming things work on a particular platform when they may not.
also, people who download the CVS tarball will have to do the same thing.

for example, when we create a release, we may be using a newer/older 
version to create the derived files.  bad.

i'm running...
autoconf (GNU Autoconf) 2.53
automake (GNU automake) 1.6.3
ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52)

how would you like to handle this?

right now, we are all running different version and clobbing each others 
derived files with every checkin.  

-matt


Reply via email to