proposal for common configuration elements for ITAPS services

[Vitus Leung]

Jason,

I have a concern about the second difference from common systems in that a single system for all libraries, ITAPS and non-ITAPS, might be easier for the user.

Vitus

On Aug 26, 2010, at 5:45 PM, Jason Kraftcheck wrote:

> 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
> 
> 
> 
>