proposal for common configuration elements for ITAPS services

[Mark Miller]

So, keep controls for individual stuff. That is fine.

What I am saying is that in order to be ITAPS-compliant, MOAB would be
required to support --enable-itaps in addition. And, controls for
individual stuff is implementation dependendent.

In other words, the proposal is to simplify autoconf switches for ITAPS
compliance to a single switch, --enable-itaps.

Mark

On Tue, 2010-09-21 at 09:51 -0700, Tim Tautges wrote:
> This won't work for MOAB; MOAB has both an imesh and an igeom implementation, and there are (many) times when you only 
> want imesh, and not igeom.  So, we need them individually controllable.
> 
> - tim
> 
> On 09/21/2010 11:10 AM, Mark Miller wrote:
> >
> > On Mon, 2010-09-20 at 21:18 -0700, seol at scorec.rpi.edu wrote:
> >
> >> 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.
> >>
> >
> > You know, this sure would be a lot simpler than having to remember
> > several different switches. So, to paraphrase your proposal, given a
> > product like FOOBAR which implements SOME of the ITAPS interfaces,
> > --enable-itaps means to enable all the interfaces FOOBAR implements.
> > Optionally, a product could also offer --enable-<some specific ITAPS
> > interface>  but that would NOT be required by 'ITAPS-compliant' software.
> > ITAPS-compliance means only that --enable-itaps is an available
> > configuration switch.
> >
> > I kinda like this idea.
> >
> > Mark
> >
> >
> >
> 
-- 
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