proposal for common configuration elements for ITAPS services

[Jason Kraftcheck]

We have decided on common configuration options used to specify the 
ITAPS implementations to be used by services.  I think that it would be 
nice if all ITAPS codes followed a common convention for these options. 
  I propose that the group adopt the system we use.  I'll describe the 
system and the reasoning behind the choices below.


The system we have decided on uses autoconf variables that point to the 
i*-Defs.inc file provided by the implementation.  The names of the 
variables are all-uppercase of the form I*_DEFS.  An autoconf variable 
is created in the configure.ac with a statement like the following:
   AC_ARG_VAR( [IMESH_DEFS] , [Path to iMesh-Defs.inc] )

The following are examples of three slightly different syntaxes that can 
be used to configure Mesquite with iGeom and iMesh support:

Example 1:
   ./configure IMESH_DEFS=/home/jason/moab/lib/iMesh-Defs.inc \
               IGEOM_DEFS=/home/jason/cgm/lib/iGeom-Defs.inc

Example 2:
   IMESH_DEFS=/home/jason/moab/lib/iMesh-Defs.inc \
     IGEOM_DEFS=/home/jason/cgm/lib/iGeom-Defs.inc \
     ./configure

Example 3:
   export IMESH_DEFS=/home/jason/moab/lib/iMesh-Defs.inc
   export IGEOM_DEFS=/home/jason/cgm/lib/iGeom-Defs.inc
   ./configure


This system differs from other common ones in two significant ways. 
Firstly, it uses an autoconf variable rather than an --enable-* or 
--with-* flag.  Secondly, the value is expected to be the full path to 
the *-Defs.inc file, rather than some directory containing the file.

The reason for the first choice (autconf variable) is that it makes 
configuring many services that are all build against the same 
implementation(s) (e.g. all services are to be used in the same app) to 
be configured more easily.  A statement like
   export IMESH_DEFS=/home/jason/moab/lib/iMesh-Defs.inc
will store a value in the shell environment that can be used by all 
subsequent configures of different services without specifying it again.

Allowing the value to be specified as an environmental variable is also 
more likely to be compatible with build systems that are implemented 
wiht cmake.  Cmake has a very different syntax for command line 
arguments, but can still access environmental variables.

The reason for the second choice (full path to *-Defs.inc) is that it is 
the most straightforward and least error prone way to implement the 
configure script.  It is also entirely sufficient:  the defs file should 
contain all the information the service needs.  No other path 
information should be necessary.  Many implementations currently accept 
a value that corresponds to the --prefix where the implementation was 
installed.  They then expect the defs file to be at the libs/*-Defs.inc 
relative path.  This will break if --libdir was specified explicitly to 
the configure script as something other than the lib/ subdir of $prefix. 
  It also precludes using the i*-Defs.inc files from un-installed MOAB 
or CGM builds (which is supported).

Another useful feature of this is that it is proof against non-standard 
names for the *-Defs.inc files, for example if a file must be re-named 
to avoid conflicts with another implementation.  Finally, it is the 
least error-prone for the user if they are using tab-completion in the 
shell because by the time they have the whole option specified the shell 
has verified that it is correct (to have reached the file with tab 
completion, the file must exist.)

- jason