proposal for common configuration elements for ITAPS services

[Tim Tautges]

On 09/20/2010 10:52 PM, Mark Miller wrote:
> Resending with an additional issue...
>
> In a recent email, the following issues were raised which I think add to
> this discussion...
>
> A. Standardization of autoconf support for MPI. --with-mpi is one
>     way to handle it. CC=mpicc is another.

As a general note, I don't think the CC= solution will be an acceptable substitute for --with-mpi; that would require 
the configure script to parse the contents of CC, and would be ambiguous e.g. if only CC were input and not CXX and F77/FC.

> B. Does --enable-imeshp imply --enable-imesh? If so, are there
>     other cases of implied dependency between ITAPS interfaces we
>     need to consider/address?
> C. Should the default for --enable-i<whatever>  for all implementations
>     be a) the same and b) ON by default. So, you have to specify
>     --disable-i<whatever>  or --enable-i<whatever>=no to explicitly turn
>     it off? I'd argue yes, the default should be ON.
>

I would strongly resist imposing requirements on the default of these options, I don't think we should bind 
implementations that way.

- tim

> Mark
>
> On Fri, 2010-09-10 at 07:54, Carl Ollivier-Gooch wrote:
>> So returning to this subject (as per Karen's request), I have two
>> suggestions:
>>
>> 1.  For -implementations-, which need to know at configure time whether
>> to build support for an interface, I propose we use:
>>
>>     --enable-imesh
>>     --enable-imeshp
>>     --enable-igeom
>>     --enable-irel
>>     --enable-ifield
>>
>> Currently: of four implementations, we have --enable-imesh,
>> --enable-iMesh, --enable-itaps, --enable-tsttm (the ref implementation
>> needs no flag here, for obvious reasons).  Lower case seems preferred
>> (and is typical for configure options).  And imesh is definitely the
>> right thing to append (he says, despite currently using something else).
>>    Unless someone has strenuous objections, we should standardize to
>> this, ideally before the next buildapolooza in a week and a half.
>>
>> 2.  For services and applications, which "only" need to know where to
>> find some include and link info, I find Jason's argument in favor of
>> using autoconf environment variables compelling, especially the part
>> about being able to build multiple components more easily.  What do
>> other people think about adopting this as a standard for all our services?
>>
>> Carl

-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
          phone: (608) 263-8485      1500 Engineering Dr.
            fax: (608) 263-4499      Madison, WI 53706