proposal for common configuration elements for ITAPS services

[Miller, Mark C.]

Hi Jason,

Ok, so I have a case in which I prefer NOT specifying path to i*-Defs.inc at
configure time and would rather do it at make time. That is when I am building
eyeMesh browser. In reality, maybe that code really isn't complex enough to
require autoconf anyways. I mean eyeMesh really only needs to know where
QT is, the C++ compiler and maybe VTK (but that is optional I think)

But, the way I do things now. I configure once and then make 3 times; once
for each implmentation using 'make -I <path-to-dir-containing-defs-file>.

eyeMesh is simple so maybe re-configuring and re-making (instead of just
re-making) for each impl is ok.

But, what about a substantially larger code which
has only a few files that depend on headers from the ITAPS implementation?
Does that mean I'll have to re-compile the WHOLE code base because I
have to re-configure it for each implementation? I'd like to avoid that and
re-compile and re-link ONLY the essential pieces. Do the producers of
the code have to be sensitive enough to this problem that they get their
dependencies correct and is that going to be difficult?

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