Bring r26503 & r26528 from autotools_rework branch back to the trunk:
Remove old platform configure files: craynv, dec-flags, hpux11.23,
ia64-linux-gnu, nec-superux14.1, sv1-cray, x86_64-redstorm-linux-gnu
Also remove CONVERT_DENORMAL_FLOAT, since this was only set in the
configure files being removed.
Tested on:
Linux/32 2.6.18 (jam) w/serial & parallel
(Daily tested on branch for 2+ days)
Move timing measurement routines used by h5perf and h5perf_serial to tools/lib
so that they can be used by other tools too.
tools/lib/io_timer.c
tools/lib/io_timer.h
tools/perform/io_timer.c
tools/perform/io_timer.h
renamed perform/io_timer.[ch] to lib/io_timer.[ch]
tools/lib/Makefile.am
tools/lib/Makefile.in
tools/lib/CMakeLists.txt
tools/perform/Makefile.in
tools/perform/Makefile.am
tools/perform/CMakeLists.txt
MANIFEST
updated due to the move.
Tested; h5committest and jam (serial)
tools/perform/sio_timer.h:
tools/perform/pio_timer.c:
tools/perform/io_timer.h:
tools/perform/io_timer.c:
Renamed pio_timer.[ch] as io_timer.[ch];
merged content of sio_timer.[ch] into io_timer.[ch] so that both h5perf and h5perf_serial
call the combined io_timer.[ch].
Moved the debug printing code segment in set_time() in [sp]io_timer.c to as debug_start_stop_time() in [sp]io_perf.c where it belongs.
Screened out set_timer_type() and get_timer_type() which were not used by any code.
tools/perform/Makefile.am:
tools/perform/Makefile.in:
tools/perform/CMakeLists.txt
Adjusted to use io_timer.c for both h5perf and h5perf_serial.
tools/perform/pio_perf.c:
tools/perform/sio_perf.c:
tools/perform/pio_perf.h:
tools/perform/sio_perf.h:
Renamed [sp]io_time_destory() to same io_time_destroy();
Moved the debug printing code segment in set_time() in [sp]io_timer.c to as debug_start_stop_time() in [sp]io_perf.c where it belongs.
tools/perform/pio_engine.c:
tools/perform/sio_engine.c:
Removed #include io_timer.h since it was already #include by [sp]io_perf.h.
MANIFEST:
Updated the merge of [sp]io_timer.[ch] into io_timer.[ch].
Tested: h5committest and jam in extra.
h5diff issues "unable to read attribute" error message when comparing two files
Description:
h5diff did not handle attributes of variable length strings correctly. It created the wrong memory type if one but not both compared attributes are of the variable strings type. It ended in H5Aread() failure.
Solution:
We decided to treat the case when one type is variable length string and the other is not as incomparable. That bypassed the above error. We still need to figure out the proper way, if possible, to compare variable string with non-variable string types.
Tested: h5committested plus tested in Swallow (OS X 10.8).
and examples.
Platforms tested: Manual testing in place and using srcdir on jam, platypus, and emu with default and
PGI, Intel and new GNU compilers. ifort compiler was also tested with -i8 and -r8 flags
on jam. CMake tested on jam.
Remove all traces of MPI-POSIX VFD and GPFS detection/code.
Remove remaining traces of stream VFD.
Remove testpar/t_posix_compliant test (it's not actually verifying anything).
Clean up H5D__mpio_opt_possible() further.
Moved environment variable that disables MPI collective operations into
MPI-IO VFD (instead of it being in src/H5S.c).
A few other small code cleanups.
Tested on:
Mac OSX/64 10.9.2 (amazon) w/parallel & serial
KitWare recommendations: Change CMake commands to lower case.
Bump up CMake minimum versions.
Split test file into separate file for h5repack test.
Tested: local linux
Check in Mohamad's changes to support collective I/O on point selections,
along with some other minor cleanups.
Tested on:
Mac OSX/64 10.9.2 (amazon) w/parallel & serial
(h5committest forthcoming)
view objects. The addition of view objects in the fastforward project
is expected to be brough into the trunk sometimes in the future, which
is why we need to make this change.
Tested Manually on Jam and Ostrich.
Tested with h5commitest - Koala with intel compilers failed, but nothing had to do with those changes.
error on Koala: error while loading shared libraries: libirng.so
This is needed to avoid a conflict with the Read Context object to be
introduced in another Project.
No impact on users, since this is a private module, and low for
developers as the RC module use is very sparse in the library.
Tested with h5committest.
