H5Part development and discussion

[Achim Gsell <achim AT cybercity.ch>]

Hi John

On Thursday 10 January 2008, John Biddiscombe wrote:
> I recently updated H5Part and had compile errors
>
> Briefly outlined
> 1) _debug was defined as h5part_int64_t in one place and
> unsigned (int) in another
> 2) int32_t is undefined on win32 (use __int32)
> 3) MPIComm is defined as int in mpi.h (win32) and
> hpmp_comm_s*(linux) but #defined as unsigned long in h5Part
> (h5_types.h)
> 4) unistd.h not available openclose.c define _open/_close for
> win32 5) mpi needs to be #included before h5/h5_types when
> using cpp compiler

Thank you for your bug report! I will fix this soon.

*** BIG FAT WARNING ***
The software in the "trunk" branch of the repository is under 
development and in a pre-alpha status. I'm currently writing an 
extension for mesh-structured data and there are lot of untested 
changes in the code. To be honest: At the moment I'm glad, if it 
*compiles* under Mac OS X ;-(

For productive use you should use version 1.4. Some of the errors 
may be in this version too, I will check this!
*** END WARNING ***


> I'd also like to flag a problem that I have.
> It is possible to have HAVE_PARALLEL (+H5_HAVE_PARALLEL) false
> when building hdf5, but to 'yes' have mpi present. This case
> is not handled correctly by H5Part as it only has a flag for
> PARALLEL_IO - in this case MPI is not pulled in and errors
> occur. (in particular 3) above is manifested because
> PARALLEL_IO is false, but we have included MPI so we get a
> false redefinition- in fact my patch might cause trouble
> there, so best leave 3 out

Do I understand you right? You have case where you compile HDF5 
serial but with MPI? Is this reasonable? If yes: In which cases?

Achim