proposal for common configuration elements for ITAPS services

[seol at scorec.rpi.edu]

> 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.
> B. Does --enable-imeshp imply --enable-imesh? If so, are there
>    other cases of implied dependency between ITAPS interfaces we
>    need to consider/address?

We are working on interface-independent ibase implementation which contains entity set and iterator sharable by all
other interfaces, which implies that --enable-i(mesh/meshp/geom/rel) will imply that --enable-ibase is on. I also
think the dependency might exist if --enable-irel is on.

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

Instead of individual option for each implementation (imesh, igeom, irel, etc), how about --enable-itaps for all.
In case of imeshp, having both --enable-itaps and --with-mpi (or CC=mpicc) would be interpreted as imeshp enabled.

Switching to have --enable-i*** by default would work for SCOREC S/W. However, we didn't have --enable-ixxx by default
on purpose since users cannot take full advantage of SCOREC S/W functionalities through ITAPS.

Seegyoung

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