It looks like this didn't make it into netcdf-4.1. Are there plans to
put it in the next patch release? Do you have a patch of the proposed
fix I can try on my local copy?
Thanks,
--Greg
On 10/07/2009 01:47 AM, Ed Hartnett wrote:
> Rob Latham <robl@xxxxxxxxxxx> writes:
>
>
>> On Tue, Oct 06, 2009 at 10:25:01AM -0600, Dennis Heimbigner wrote:
>>
>>> If you write a program that includes
>>> mpi.h then indeed you will get conflicts;
>>> so the question is: why are you including
>>> mpi.h in your netcf programs? Does it work
>>> ok if you remove the '#include <mpi.h>' ?
>>>
>> Here's what we do in pnetcdf. Any place that pnetcdf needs MPI data
>> structures, we include <mpi.h> we do not, however, include mpi.h in
>> the pnetcdf.h header file.
>>
>> Because the pnetcdf API uses things like communicators and MPI info
>> values, we force the caller to include mpi.h before including
>> pnetcdf.h
>>
>> Our job is easier because we are always parallel, whereas netcdf-4
>> might not have parallel I/O support if the underlying HDF5 library
>> does not have it.
>>
>>
> As I understand it, the reason this problem comes up is because some
> users have parallel programs which use sequential netCDF. So the user
> program contains the include for mpi.h, but sequential netCDF has
> redefined MPI_Comm and MPI_Info.
>
> I think the smart thing to do might be to have a separate header
> netcdf_par.h, which is included by people who want to use parallel
> I/O. This way, the sequential header (netcdf.h) does not need to contain
> anything related to mpi.
>
> Right now, I also build nc_create_par/nc_open_par functions whether the
> build is for parallel or not. I think I will have to change that too.
>
> I will try and get this change in before the 4.1 release, but I am on
> travel right now...
>
> Thanks,
>
> Ed
>
>
