This is for cicb developers only. It can be ignored if you're just
building the client.

GNU Autoconf
------------
This release uses the gnu autoconf system for configuration
detection. If you want to add configuration tests, you must
have autoconf installed on your system. autoconf can be
found at any gnu mirror. The main one is at ftp.gnu.org.
autoconf can be found in the pub/gnu/autoconf directory.

Note: autoconf requires the gnu m4 macro preprocessor. It will
NOT work several other implementations of m4, most notably the
one that comes stock on Solaris. gnu m4 is available at
ftp.gnu.org, in the pub/gnu/m4 directory.

Docs for the gnu autoconf system can be found at any gnu mirror. 
The main one is at www.gnu.org. Specifically, you can look at
http://www.gnu.org/manual/autoconf-2.13/html_chapter/autoconf_toc.html



Adding Tests and Creating a New Configure Script
------------------------------------------------

Basically, if you need to add a check to the configuration system,
you modify configure.in and then rerun autoconf. For simple things,
you should try to use the macros that the autoconf system provides;
see the autoconf docs for details. If you have to do something more
complex, you'll want to define your own macro and add it to the
aclocal.m4 file, and then call your macro in configure.in. Your macros 
can call other macros (including the built-in autoconf ones) and can 
have sh commands embedded in them.

Once you've added your check, you need to run autoreconf to regenerate
the configure script. This takes your configure.in and aclocal.m4
and runs it through the m4 preprocessor to merge all the macros
and convert the whole thing to a single sh script, "configure".



What Happens When You Run Configure
-----------------------------------

The way it's set up here, configure, when run, does three things:

1) It performs a variety of checks. 

   Some of those checks will result in internal variables being 
   defined, and some will result in ifdef's.


2) It creates config.h in this directory, using config.h.in as a template. 

   Ifdefs will get written out to config.h. All sources should #include 
   this file (usually before other #includes). config.h gets created by 
   reading config.h.in, but it's sort of peculiar - for every
   #define you want configure to set, you have to create a #undef in
   config.h.in. So, if you ask configure to check for the existance
   of the socket() function, you'll add  "#undef HAVE_SOCKET" to
   configure.h.in, and when configure runs, it will change that to
   "#define HAVE_SOCKET 1" if socket() was found. If it wasn't found, 
   it will leave it undeffed.


3) It creates Makefiles in various directories, using the Makefile.in
   files in those directories as templates.

   The top level Makefile.in will get copied over to Makefile, and the
   internal variables defined in step 1) will get substituted for @VARIABLE@.
   e.g. if configure has determine that RANLIB is "ranlib" (see the 
   AC_CHECK_PROG directive in configure.in), all instances of @RANLIB@ in
   Makefile.in will get replaced with the string "ranlib". The same goes for
   murgil/Makefile.in and icb/Makefile.in.


Configure also creates a couple of ancillary files. It will create a
config.cache to save the results of your run; it will create a config.log,
which is handy for figuring out what happened when things go wrong, and it
creates a few files for its own use.

If you need to run the configure process over again to test your
changes, you'll probably want to remove config.cache.



Checking into CVS
-----------------

Occasionally when you check things into CVS after having modified the
aclocal.m4 or configure.in, you'll get collisions in the configure
script. Since configure is an autogenerated file, usually the easiest 
thing to do is to make sure you don't have any OTHER conflicts, rerun
autoconf, and then re-check-in the configure script.



Michel Hoche-Mong
12 Oct 2000
hoche@grok.com
