proposal for common configuration elements for ITAPS services

[Mark Miller]

Hi All,

I just wanted to follow-up on this thread with a code-snipit I added to
eyeMesh browser's configure.in file...

#
# Setup IMESH_DEFS variable
#
AC_ARG_VAR(IMESH_DEFS, [Path to iMesh-Defs.inc] )
if test -z "$IMESH_DEFS"; then
    AC_MSG_ERROR(IMESH_DEFS variable not specified)
else
    if ! test -r $IMESH_DEFS; then
        AC_MSG_ERROR([The file specified for IMESH_DEFS, "$IMESH_DEFS", either does not exist or is not readable])
    fi
fi

I propose that this configure logic is placed as close to the 'top' of
configure.in as possible so that configure will stop as soon as possible
if there is a problem with IMESH_DEFS variable.

Also, the logic above does a couple of extra checks. First, it checks
that indeed the variable was defined (e.g. non-emtpy string) and second
that it references a file that is indeed readable. I suppose it could go
further to confirm the name of the file is 'iMesh-Defs.inc'.

Tim recommended a different phrase for what 'configure --help' prints
out for IMESH_DEFS. Above, it says, 'Path to iMesh-Defs.inc'. Tim
suggests 'Full path-qualified location of iMesh-Defs.inc file'. There is
some ambiguity as to whether 'path' means 'the directory containing' the
file itself. I am not sure what best simple phrase would help to address
it but since my configure bombs out almost immediately if its specified
incorrectly, I think the ambiguity can be quickly/easily resolved.

Mark



On Thu, 2010-08-26 at 16:45, 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
> 
-- 
Mark C. Miller, Lawrence Livermore National Laboratory
================!!LLNL BUSINESS ONLY!!================
miller86 at llnl.gov      urgent: miller86 at pager.llnl.gov
T:8-6 (925)-423-5901    M/W/Th:7-12,2-7 (530)-753-8511