itaps-parallel DOCUMENTS subdirectories

[Onkar Sahni]

In summary I do not think I agree with these two points, for details see
below.

In case of MPI, one CANNOT include mpi.h from openmpi and link against
mpich1 (or some other combination) and expect things to work. In case of
ITAPS, an app. will include one and only one iMesh.h and then finally link
against any implementation (not a particular one).

Moreover, I can easily imagine a situation where a service Sr1 was build
using a.x version of header from a particular implementation Im1 and an
app. Ap1 wants to use implementation Im2 using b.y version of headers
along with service Sr1 but now service Sr1 need to support another build
using b.y version of headers coming from implementation Im2.

If apps are willing to risk inconsistency then they can do whatever they
want (doesn't matter whether which way we follow on headers)... in general
I would not prefer apps to go and have their own (extra) declarations in
iMesh.h rather they can have extras in iMesh_extra_app1.h.
If apps want to change existing iMesh.h functions (say a app. want to
change arguments in iMesh_getAllVtxCoords) then we do not accomplish
interoperability and further, what I suggested doesn't change anything for
such apps.

- Onkar

> PS - I don't thing that precludes apps keeping their own declarations of
> iMesh.h functions if they like, and if they're willing to risk
> inconsistency with the implementation's definitions of these functions.
>
> - tim
>
> Tim Tautges wrote:
>> I don't think that's a good idea; for example it would be inconsistent
>> with the way MPI does things.  If somebody's using just one
>> implementation, we don't want to require them to go get iMesh.h from
>> somewhere else.  That does put an obligation on implementations to be
>> consistent with the standard iMesh.h file.  That's one good reason for
>> having version numbers and functions, so the application can compare
>> against what it expects to get if it's sensitive to that.
>>
>> - tim
>>
>> Onkar Sahni wrote:
>>> Lori,
>>>
>>> Thats a good point and we (RPI) very much want it this way.
>>>
>>> Infact we would prefer to include all i"ITAPS".h header files from a
>>> central location instead of using copies provided by any
>>> implementation/library (we would even prefer that implementations
>>> specifically FMDB doesn't have a copy of ITAPS header files rather it
>>> includes it from a central place, in case of applications people using
>>> their own local system they can download it from ITAPS repository and
>>> appropriately set some build parameter). I tried to make this point
>>> earlier but it got lost in some details.
>>>
>>> As per my understanding, currently each implementation/library provide
>>> a
>>> copy of ITAPS header files.
>>>
>>> Thanks,
>>> Onkar
>>>
>>>> When we create the new subdirectory that has all the tutorial
>>>> examples,
>>>> I think we should have a single subdirectory that contains the iMesh.h
>>>> iMeshP.h and iBase.h files that all the exercises can reference.
>>>> Essentially Karen's DOCUMENTS directory from Hello.  Martin also
>>>> refers
>>>> to these functions and it doesn't make sense to repeat the
>>>> subdirectory.  I'd probably change the name to be more iMesh specific
>>>> -
>>>> something like iMESH_INCLUDES or iMESH_DOCS.
>>>>
>>>> We'll also need a high level README that describes each of the
>>>> exercises
>>>> at the highest level.
>>>>
>>>> Just wanted to get these ideas out into public space - no immediate
>>>> action items.
>>>>
>>>> Lori
>>>>
>>>>
>>>
>>>
>>>
>>
>
> --
> ================================================================
> "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
>
>