Description:
A typo in the project output file name was causing Intel Fortran 10.1 to crash. The output file was set to "$(OutDir)\hdf5_fortranddll.dll " (three trailing spaces). IVF 9.1 ignored this error and continued gracefully. However, IVF 10.1 would simply crash. With this fix, we can now build on IVF 10.1 (so far..)
Tested:
VS2008 w/ IVF 10.1 on WinXP
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:
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:
On Windows, we receive many compiler warnings because Microsoft has implemented many "security-enhanced" versions of POSIX functions. However, the old versions still exist, so the warnings can be ignored. By setting a preprocessor definition, we can disable many of these warnings. On a typical HDF5 build, this reduces the number of warnings from ~1500 to ~600
Tested:
VS2005 on WinXP
Description:
These changes are made via a user's suggestion, bugzilla bug #1164. These have all been tested in the trunk, and are stable/favorable changes.
In many of our project files on Windows, we have our linker setting set to ignore old link libraries-- either libc.lib or libcd.lib. This is a relic from converting project files from old versions of Visual Studio to newer ones, and is unnecessary. We remove the ignored library from the project files. This actually makes no difference in the output binaries.
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.
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
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
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:
VS.NET 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:
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:
The ohdr_gentst project exists to dynamically generate the test files for ohdr test, which also exist in the repository. The test is only run on other platforms when the configure flag --enable-build-all is specified. Moreover, the source code ohdr_gentst.c is marked as _DO_NO_DISTRIBUTE_ in the MANIFEST.
As a result, there was a problem in the release tarball that the Windows projects would fail when trying to build this project. To correct this, we no longer build this by default. We will also need to release a FAQ/patch for the HDF5 1.8.0 release.
Tested:
VS2005 on WinXP
Description:
Add hdf5 library as a dependency to hdf5_hl library in Windows project files
For some reason, the hdf5_hl library didn't have hdf5 listed as a dependency. This isn't normally a problem, because building "all" will build hdf5 library. However, when a user tries to build only hdf5_hl, hdf5 library wouldn't be built.
Although not technically required for compiling the library code, the hdf5 library is needed for linking any applications, so it's a natural dependency.
Tested:
VS2005 on WinXP
VNET on WinXP
Description:
This catches up Windows to most of the new source files that have been added. Specifically, H5FDpkg.h and H5FDspace.c have been added to the library projects, and tcoords.c has been added to testhdf5. This goes for VS2005 and VS6 project files.
Tested:
Only built, VS2005
Description: The stream file driver was recently removed from the HDF5-1.8 source. This checkin removes any left-over references in the Windows projects.
Tested:
VS2005
Description:
Previously, we provided a static h5tinit.c with our Windows distribution, and provided instructions to optionally generate it. Now, we will incorporate it as part of the default build process, to emulate other platforms more closely.
Tested:
VS6
VS2005
Description:
Add toolslib(dll) as a dependency to h5import(dll), to support the new -V flag. This needed to be done in each of our 3 solution files.
Tested:
Only built, VS2005 and VS6
Description:
-- Add new source files to Windows projects: H5Pdeprec.c, H5Pint.c, H5Ddbg.c, H5Dint.c
-- Add new h5dump XML tests to Windows test script
Tested:
VS2005 on WinXP
Description:
This checkin is another Windows project cleanup, and also extends our Windows support for 64-bit Fortran. Project files are now in VS2005 format, rather than VS.NET. A couple projects have been renamed to be more descriptive (*cstub rather than *_lib), and project settings make better use of build macros. This will make them much easier to update in the future.
Tested:
VS2005 on WinXP 32-bit
VS2005 on WinXP x64
Description:
We are porting Fortran to 64-bit Windows, and need to make many syntactical changes to bring the code up to date. We now go back to using "!DEC$" rather than "!MS$" in our "ATTRIBUTE" code. Also, the naming conventions for mixed language is inconsistent from 32- to 64- bit Windows. To make up with this, we use the "decorate" flag. We also needed to change the "calling convention" in project settings from "CVF" to "default".
Also other minor cleanups on project files.
Tested:
32-bit: VS.NET and VS2005
64-bit: VS2005
Description:
At a previous seminar, it was brought up that the naming scheme for Windows debug DLL is inconsistent. Specifically, some use *ddll, while others use *dlld. *dlld is more widely-used, so we decided this is "correct". This changes others to use this scheme, and adapts other projects / install scripts / documentation.
Tested:
Visual Studio .NET on WinXP
Description:
- Add new source file H5version.h to Windows projects
- Add new h5stat tests, and uncomment one that no longer fails
- Clean up autotests a little bit.
Tested:
VS.NET on WinXP
Desciption:
This is the first major check-in in the process of depreciating Visual Studio 6.0. We create a new directory, windows_vs6, which now holds all of our previous VS6 project files. We expect to maintain this directory for only a short time (perhaps one release), so users have time to make the change.
The ./windows directory now contains project files for Visual Studio .Net, as well as existing source and test scripts. This will allow us to greatly simplify the build process for the majority of our users.
We have created a new solution (.Net equivolent of workspace) that houses the Fortran project files. This allowed us to remove these files from the main solution, as well as streamline the conversion in the Fortran solution. It is also much easier now to convert to Visual Studio 2005 files.
Notes:
I didn't update the MANIFEST with this check-in, I will make those changes shortly.
Also, I haven't yet updated the documentation to reflect this check-in. That is going to require more work.
We will be giving a seminar in the coming weeks about .Net and how to migrate over.
Tested:
VS6/VNET/VS2005 on WinXP 32/64-bit
Also added a Windows-specific macro, WINDOWS_USE_STDIO, which users can define if they'd like the Windows VFD to use the buffered low-level I/O functions. This is instead of splitting our Windows driver into two separate drivers. By default, this macro is undefined.
Tested:
VS6 on WinXP
./c++/test/tcompound.cpp
./c++/test/ttypes.cpp
./c++/test/tfilter.cpp
./c++/test/tvlstr.cpp
Also, fixed a declaration in ttypes.cpp that was causing a compile error in MSVS6.0.
Tested:
Visual Studio 6.0 on WinXP
kagiso
too minor for h5committest
H5Obtreek.c and H5Odrvinfo.c in hdf5.dsp and hdf5dll.dsp
h5repack_ref.c in h5repack.dsp, h5repackdll.dsp, and h5repacktst.dsp.
Tested:
Visual Studio 6.0 on Windows XP
Visual Studio 8.0 on Windows XP 64-bit
Tested 1.6 compatibility feature: work for vs studio 6.0
Corrected several small bugs inside tool batch files
Add a few project files to test error APIs
