proposal for common configuration elements for ITAPS services

[Miller, Mark C.]

Hi Jason,

An additional reason I kinda like this is that it sort-of serves as a 'short-hand' for ALL
the path information stored in the i-*Defs.inc file.

One question though, doesn't your second example require an 'env' in front of the whole
command? I mean, I don't think csh or tcsh can handle that invokation WITHOUT 'env'
in front of it like so...

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

Mark

________________________________________
From: tstt-interface-bounces at lists.mcs.anl.gov [tstt-interface-bounces at lists.mcs.anl.gov] On Behalf Of Jason Kraftcheck [kraftche at cae.wisc.edu]
Sent: Thursday, August 26, 2010 4:45 PM
To: tstt-interface
Subject: proposal for common configuration elements for ITAPS services

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