Description: Test gcov script on kagiso
Solution: The bin/gcov_script was not working on kagiso (it was written to
be used on heping, but since we don't have heping anymore, we
need it on kagiso). There was a problem in that the generated
.gcda files were being created in the /src/.libs directory when
the script was expecting them to be in the /src directory. Also,
-lgcov was added to LDFLAGS.
The script performs configuration of HDF5 and runs the tests, and
generates code coverage statistics for the source code files,
which it places in the gcov_logs directory.
The individual *.gcov files show the number of times each
individual line of the associated source file is executed, and
displays branches tken information as well. The file gcov.log
shows a summary of each source file's coverage statistics in one
easily accessible file.
Tested: kagiso
Usage is
-m T, --format=T
Where T - is a string containing the floating point format, e.g '%.3f'
The test consists of writing a number with 7 fractional digits (default precision display of %f is 6 digits) and have the 7 digits displayed with
-m %.7f fpformat.h5
Tested: windows, linux, solaris
Note: the output file was generated in linux, it may be possible that platforms other than the ones tested have a different representation of the number
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
Description:
Two new source files have been added, H5Dchunk.c and H5Dscatgath.c. This checkin adds the files to the Windows project files as well.
Tested:
VS2005 on WinXP
Omnibus raw data I/O revisions, with wide-ranging changes and
refactoring, in order to prepare for implementing "fast append" feature.
These changes remove the majority of the code duplication for raw data
I/O which has crept in over the last ten years and introduces a more object-
oriented design for operating on different types of dataset storage.
Chunked storage no longer has it's own I/O routines, it is now handled
as either contiguous (if chunk is not pulled into the cache) or compact (if the
chunk is cached in memory).
No bug or feature changes, at least intentionally... :-)
Tested on:
FreeBSD/32 6.2 (duty) in debug mode
FreeBSD/64 6.2 (liberty) w/C++ & FORTRAN, in debug mode
Linux/32 2.6 (kagiso) w/PGI compilers, w/C++ & FORTRAN, w/threadsafe,
in debug mode
Linux/64-amd64 2.6 (smirom) w/default API=1.6.x, w/C++ & FORTRAN,
in production mode
Linux/64-ia64 2.6 (cobalt) w/Intel compilers, w/C++ & FORTRAN,
in production mode
Solaris/32 2.10 (linew) w/deprecated symbols disabled, w/C++ & FORTRAN,
w/szip filter, in production mode
Mac OS X/32 10.5.2 (amazon) in debug mode
Linux/64-ia64 2.4 (tg-login3) w/parallel, w/FORTRAN, in production mode
Description:
When building HDF5 with thread safety on Windows, the err_compat test was failing because our output was being parsed incorrectly. Rather than having a thread number in the error stack trace, there will be the string "some thread: no way to know the thread (IDs): from pthread on windows:". This checkin now takes this into account, and modifies the output accordingly.
Tested:
VS2005 on WinXP with Pthreads
Description:
On Windows, many POSIX functions have been replaced by a similarly-named function with some additional security-checking. Visual Studio issues a warning each time the POSIX version is used, recommending that we replace it with the new version. This results in thousands of errors when building the HDF5 library.
This checkin adds a Visual Studio "Property Sheet", which has been applied to all library projects, and defines a number of preprocessors to suppress these warnings. The warnings have been disabled only in Visual Studio 2005 project files, as VS.NET doesn't support property sheets.
Tested:
VS2005 on WinXP
Description:
Vailin has been working on some new tests for converting Windows paths. She found a bug that is making these two tests fail, but didn't have time to fix it. We've commented out the two tests until she has time to fix the bug. This won't affect other platforms because it's Windows-specific code.
Tested:
VS2005 on WinXP
Description:
- Revised Attribute::write and Attribute::read wrappers to handle
memory allocation/deallocation properly. (bugzilla 1045)
- Changed free() to H5Dfree(), also needed H5private.h
- Corrected quite a few typos in documenting!
Platforms tested:
SunOS 5.10 (linew)
Linux 2.6 (kagiso)
FreeBSD (duty) - there was something wrong in the C tests for makecheck
hung quite a long time; I went ahead with makecheck just in c++ dir,
since the changes didn't effect the C tests. I'll keep an eye on
the tests tonight...
remove HDputenv() from external_link_env() test
(will add script later to set HDF5_EXT_PREFIX for running the test)
modify and add more comments
2. src/H5private.h: remove #define for HDputenv()
Tested on kagiso, linew and smirom.
Description:
Just as we have scripts for building and testing the HDF5 library on Windows, hdf5build_examples.BAT is a new script for building HDF5 example projects on Windows. This is especially useful for our new Windows Daily Tests, to test our examples automatically as well.
Eventually, we will have hdf5check_examples.BAT and hdf5bt_examples.BAT to test our examples as well.
Tested:
VS2005 on WinXP
Description:
Previously, our Windows projects for HL Fortran examples were using outdated library names for our cstub code. As a result, they wouldn't build correctly. This checkin brings them up-to-date.
Also, add hdf5_hl.lib as a dependency to hdf5_hl_fortran.lib. This goes un-noticed when building the complete VS solution, but should be required when only building hdf5_hl_fortran.lib
Tested:
VS2005 on WinXP
Description:
In the Windows Fortran example projects, the runtime library used for linking static-debug version was set incorrectly. This was a result of the project being upgraded from VS6 where we used Single-threaded libraries. Those libraries are no longer supported, so we use [Debug] Multithreaded [DLL] now instead.
Note that this also needs to be updated in the VS.NET project files-- I will make those changes shortly.
Tested:
VS2005 on WinXP
Description:
Many new path-specific tests have been added via the "links" test. Because Windows' path format is non-standard, we need a special macro defined to handle it specially. Note that 2 tests still fail with this macro defined, but it should be fixed soon.
Tested:
VS2005 on WinXP
Description:
The ohdr_gentst project exists in order to re-create test input files that are distributed with the source. These projects aren't built by default on most platforms, and the source isn't distributed in release builds. To avoid confusion and bloat, we remove the Windows version of this project.
Tested:
None, only removed
Description:
In previous versions of Windows, the builtin 'FC' command (diff equivalent) didn't return proper exit status. As a work-around, we parsed the message returned to check status. This relies on English return messages.
In current Windows XP and Windows Vista, FC will return exit status as expected, so we can remove this workaround. Older platforms where we would need this workaround are no longer supported.
Tested:
VS2005 on Windows XP
Small test on Windows Vista
H5_DLL herr_t H5_build_extpath(const char *, char **/*out*/);
makes this stupid warning in windows that gets repeated in every source file
c:\_pvn\hdf5\src\h5private.h(958) : warning C4138: '*/' found outside of comment
changed signature to
H5_DLL herr_t H5_build_extpath(const char *, char ** /*out*/ );
compiler is happy now
tested: windows, linux
