the way h5ls prints types, it starts searching for NATIVE types first. One solution would be h5ls not to detect these native types, using for example the same print datatype function that h5dump does, that would make the output look the same on all platforms ("32-bit little-endian integer" would be printed instead). Drawback, this "native" information would not be available. Other solution is to have not one but 2 expected outputs and make the shell script detect the endianess and compare with one output or other
tested: h5committest
Description:
- Remove need to set LD_LIBRARY_PATH when using shared szip library.
- Libtool 2.2.6a is now used to generate libraries.
- 'make check install' dependency bug is fixed, and should no longer
break the build.
- removed hard coding of shell in config/commence.am, as this causes
problems on Solaris with the new version of libtool.
- RELEASE.txt with appropriate changes.
Tested:
- kagiso, smirom, linew (merged from 1.8, pretty quick tests)
Changed the error output formatting so that the
test status writes to standard out looks correct when using the
sun compiler (it did not correctly tab the output).
Uninstall target had non-existant file to remove; error_handler module triggered
a race condition for parallel make with Intel and PGI compilers, therefore we
removed the module and created a subroutine instead.
Platforms tested: kagiso with GNU, Intel and PGI compilers.
Added code to remove module files when make clean
Description:
The module files were not being removed when make clean
and caused compiling errors. fixed.
Made reporting of the test status global by handling the output
via a module. Cleaned-up output to the terminal.
Description:
Put writing the test status as a call to a subroutine
instead of on a per account basis.
Added the dependency of compiling in the correct order
in the Makefiles for use of the Module.
Description:
The fortran Makefile.am used HDF_FORTRAN to indicate it is part of the
Fortran API source so that conclude.am will give fortran api prefix in the
test output. The symbox HDF_FORTRAN is also used in configure for a different
purpose (indicated --enable-fortran). They conflicted.
Similar problem for the symbol HDF_CXX.
Solution:
Changed all the involved Makefile.am to use "FORTRAN_API" instead. It is
a more appropriate name. Same for CXX_API.
Along the way, discovered that the Makefile.am of hl/fortran/test and
hl/cxx/test did not have those symbols at all. Added them in.
Platform tested:
Kagiso only. It is a trivia change.
Cleaned up unused code (i.e. commented out) and removed extraneous output to standard out.
Tested:
N/A - No critical executable source lines were modified, only comments and write statements.
Improvement.
Description:
src/libhdf5.settings was the initial configure summary and is installed.
Then configure is changed to dump a summary of the configure settings to
the output and also append it to src/libhdf5.settings. That created
two different output formats and duplicated information. This is the
initial attempt to clean up this confusion and unify the output format.
It is decided to use the src/libhdf5.settings template as the unified means.
This requires more macros symbols be defined. The following symbols are
all related to generating the src/libhdf5.settings file.
AC_SUBST(EXTERNAL_FILTERS)
AC_SUBST(MPE) MPE=no
AC_SUBST(STATIC_EXEC) STATIC_EXEC=no
AC_SUBST(HDF_FORTRAN) HDF_FORTRAN=no
AC_SUBST(FC) HDF_FORTRAN=no
AC_SUBST(HDF_CXX) HDF_CXX=no
AC_SUBST(CXX) HDF_CXX=no
AC_SUBST(HDF5_HL) HDF5_HL=yes
AC_SUBST(GPFS) GPFS=no
AC_SUBST(LINUX_LFS) LINUX_LFS=no
AC_SUBST(INSTRUMENT) INSTRUMENT=no
AC_SUBST(CODESTACK) CODESTACK=no
AC_SUBST(HAVE_DMALLOC) HAVE_DMALLOC=no
AC_SUBST(DIRECT_VFD) DIRECT_VFD=no
AC_SUBST(THREADSAFE) THREADSAFE=no
AC_SUBST(STATIC_SHARED)
AC_SUBST(enable_shared)
AC_SUBST(enable_static)
AC_SUBST(UNAME_INFO) UNAME_INFO=`uname -a`
The src/libhdf5.settings.in has CONDITIONAL's added to it too. The
untrue conditions turned into a "#" and these lines are cleaned by the
post processing script.
Platform tested:
h5committest on kagiso, smirom and linew.
Description:
There were a number of small tweaks we needed to make to add the new fortran_1_8 code on Windows. We create new project files, add new source to them, add the test to our test suite, and fix a few typos in the Windows-specific source code.
Tested:
VS2005 on WinXP
* test passing integer constant to subroutine
Description:
! -- CHECK PASSING AN INTEGER CONSTANT IN DIFFERENT FORMS --
! 1) call by passing an integer with the _hsize_t declaration
! 2) call by passing an integer with the INT(,hsize_t) declaration
! 3) call by passing a variable with the attribute hsize_t
This check-in should address Fortran failures on liberty and smirom.
Platforms tested: kagiso with Intel, smirom with g95 -fPIC, liberty with gfortran42
Description: Applying update to autotools that was applied to 1.8 a couple
of weeks ago to the trunk.
Updated bin/reconfigure script to reflect the new versions of
libtool and automake in the /home1/packages/ directory.
Rearranged configure.in script. When using libtool 2.2.2, the
libtool script doesn't generate until later in the configuration
process, so I had to move a test that parsed through the libtool
script to a point after where it was actually being generated.
Ran libtoolize on the project, and ran bin/reconfigure to
regenerate configure and Makefile.in's throughout.
Tested: kagiso, smirom, linew (h5committest)
Currently only one test (dense attributes) is failing. It looks like C library problem and we
have a similar bug report in Bugzilla: when dense storage is used, attributes are not written
to the file; somehow similar C test doesn't expose the problem while Fortran test does.
Platforms tested: linew, kagiso with g95 and PGI
Platforms tested: kagiso with PGI compilers, linew, smirom with GCC and g95 compilers;
some tests and function calls are commented out with !EP string; we will be
working on it.
Platforms tested: kagiso with g95 and Intel compilers; more testing will be done after checking in a fresh
copy from the trunk. New code itself was tested with all Fortran compilers available at THG
