Small clean up of datatype copying.
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.3 (amazon) in debug mode
Linux/64-ia64 2.4 (tg-login3) w/parallel, w/FORTRAN, in production mode
for now, the test script just calls the tool binary with the command line parameters, with no special
checking of the accuracy of the output contents (jpeg files)
tested: linux
for now, just added "-ljpeg" to the list of libraries, until a permanent solution is added to configure --with-jpeg= that would allow users to specify their own jpeg libary
tested: linux (kagiso, that has a jpeg library installed)
Update the gcc flags for version 4.3
Clean up warnings
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.3 (amazon) in debug mode
Linux/64-ia64 2.4 (tg-login3) w/parallel, w/FORTRAN, in production mode
Add a "HDcompile_assert" macro for assertions that can/should be checked
at compile time, as opposed to run time. (And used it for a couple of simple
cases, to begin)
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.3 (amazon) in debug mode
Linux/64-ia64 2.4 (tg-login3) w/parallel, w/FORTRAN, in production mode
Avoid leaking memory when copying the internal "shared" struct for
a named datatype when it's already been opened earlier.
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.3 (amazon) in debug mode
Linux/64-ia64 2.4 (tg-login3) w/parallel, w/FORTRAN, in production mode
Description:
As part of our Windows cleanup, we try to remove windows-specific tweaks in the source code. There are many instances where Windows code is introduces via ifdef's. We re-evaluate whether they are still required, and found that many of them are not. Others we change to "feature"-specific code, rather than Windows-specific.
Tested:
VS2005 on WinXP
VS.NET on WinXP
h5committest (kagisopp, smirom, linew)
Description:
On Windows, the pthread_self function cannot be used to print the returned thread ID for debugging. Instead, we need a separate function, GetCurrentThreadId. To eliminate some Windows ifdef's in the code, we create two new function macros which can be used by all platforms. It is conditionally defined in H5win32defs.h, and globally in H5private.h.
Tested:
VS2005 w/ pthreads on WinXP
kagiso w/ pthreads
Description:
The projects testhdf5_1_8fortran[dll] which test the new fortran features in HDF5 1.8 were not registered as dependencies to the "all_fortran" pseudo-project. As a result, the projects would not be built if you simply build all_fortran in Visual Studio, rather than "Build Solution". This is a very minor cleanup, but is neccessary to be consistent in our projects.
Tested:
VS2005 on WinXP x64
Description:
In library code, we try not to use system calls directly, but instead use the HD{function} macro instead. This way, we can map special versions of the call on particular systems. Previously, it was all done in H5private.h. However, in an effort to clean up platform-specific definitions, we move all of the Windows macros into a separate file, win32defs.h. This way, we can use the non-Posix versions that Visual Studio sends warnings about.
Some macros are set specifically in the platform-specific header files. Then, any macros left unset will be set by the "default" implementation in H5private.h.
This checkin also cleans up various source files to use the HD* macros when possible.
Tested:
VS2005 on WinXP
VS.NET on WinXP
h5committest (kagiso, linew, smirom)
Description: Changing h5perf installation so only h5perf is installed when
parallel is enabled, while only h5perf_serial is installed when
parallel is disabled.
Tested: kagiso
Correct the definition of the 'nbytes' variable in the in-memory version
of the B-tree key for chunks from 'size_t' to 'uint32_t', to match the
definitions everywhere else.
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/64 2.10 (linew) in debug 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.3 (amazon) in debug mode
Linux/64-ia64 2.4 (tg-login3) w/parallel, w/FORTRAN, in production mode
Fixed bug in h5ls that prevented relative group listings (like
"h5ls foo.h5/bar") from working correctly.
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.3 (amazon) in debug mode
Linux/64-ia64 2.4 (tg-login3) w/parallel, w/FORTRAN, in production mode
Finish omnibus chunked dataset I/O refactoring, to separate general
actions on chunked datasets from actions that are specific to using the v1
B-tree index.
Cleaned up a few bugs and added some additional tests also.
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:
On Linux-like systems, we can get the ID of the current thread through a pthread_self. However on Windows, the return cannot be cast as a threadID, so we simply couldn't get the ID. Previously we simply gave up and printed a message that we couldn't get an ID. Instead, though, we can use the Windows-specific call to GetCurrentThreadId(), which achieves the same goal. This way we can provide better debug output with threadsafe features.
Tested:
VS2005 on WinXP
VS.NET on WinXP
(other platforms not tested because change is within _WIN32 ifdef)
Description:
Previously, we maintained some source files that are commonly generated dynamically on other systems. Now, we also generate them on Windows as well. We should remove them from the repository so old versions are not accidentally used.
Also, clean up the project files to organize generator programs.
Tested:
VS2005 on WinXP
VS2005 on WinXP x64
VS.NET on WinXP
bug fixes.
Description:
Added code to create an empty hdf5 (named h5diff_empty.h5) in order to test
if h5diff compares correctly an empty hdf5 vs. a non-empty one.
Tested:
Tested in kagiso of h5diffgentest itself.
Verified by h5dump that h5diff_empty.h5 was indeed empty.
Then "h5diff h5diff_empty.h5 h5diff_basic1.h5" returned 0 (should have
returned non-zero).
Description: While '-Wl,-rpath' information was being removed from compile
lines when using --disable-sharedlib-rpath, some information
was still hidden in another variable tht never got reset and
thus snuck into the executables. This fix should take care of
that issue.
Tested: kagiso, smirom
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).
Description:
In some rare instances, FC (diff equivalent) command on Windows will fail when comparing ASCII files with opposite line-ending formats (Unix uses LF, while Windows uses CRLF). This was an issue for one test case in our test script. It only came up when testing from a release tarball, because the expected output was not converted to Windows-style. In this situation, FC was reporting false differences.
To workaround, we double-check failure cases and convert the EOL characters if neccessary.
Tested:
VS2005 on WinXP
Description:
Previously, there was Windows-dependent code inside H5detect.c, because not all projects could access the gethostname() function. However, we standardize our project-files to link with WS2_32.lib, so now this function is available. Thus, the Windows-specific code has been removed from H5detect.c.
Tested:
VS2005 on WinXP
VS.NET on WinXP
no need to test other platforms, Windows-specific source change
Description:
In our debug project configurations, many of the projects were generating debug information for "Program Database and Edit & Continue". Other projects were using different settings, or none at all. We standardize to use "Program Database" setting, because it generates much smaller .obj files and cuts out unnecessary debug information.
This is another project cleanup and enhancement from user suggestions outlined in bug #1164
Tested:
VS2005 on WinXP
VS.NET on WinXP
