Description:
These files were ported from the trunk to the 1.8 branch in rev. 15727. This checkin adds the new files to our Windows projects as well. In particular, we use H5_DBLE_InterfaceInclude (rather than *Exclude), and have replaced H5test_kind.f90 with H5test_kind_SIZEOF.f90.
Tested:
VS2005 on WinXP (only build)
Description:
On Windows, we manage dynamically-generated code through "post-build" steps in Visual Studio. However, the command for it wasn't checking to see if the code already existed, so it was re-generating in each build (and thus re-generating all dependencies). To overcome, we simply check if the source file exists before generating it.
Also, put all paths inside quotes so we can handle directory names with spaces.
Tested:
VS2005 on WinXP
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
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:
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:
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:
Previously the process of generating h5tinit.c, as well as the Fortran type files, was very manual on Windows. For Fortran, the process included opening 4 different solutions, and running 4 different commands from the prompt. I've made things very much more automated, and now only requires only building one project for either C or C/Fortran. Running the commands to generate the file is done automatically.
Tested: VS.NET
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:
Previously, we needed to force symbol definition "gethostname@8" for compatibility with old versions of Visual Studio. It appears that Visual Studio no longer requires this, so we remove it. This makes the build process on 64-bit much smoother.
Also minor updates to main documentation, command-line documentation, and removed codewarrior and INTEL docs.
Tested:
VS.NET
VS2005
chkmanifest
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
Support command line build HDF5 with Visual C++ .Net and Intel compiler
Description:
We can not find a way to convert workspace to solution format from command line.
typegen.sln will be provided in order to support command line build HDF5
with MSVS .Net and Intel Compiler.
Solution:
Platforms tested:
MSVS .NET on windows XP.
Misc. update:
Update project files to generate H5fortran_detect.f90
Description:
Source code in project file H5fortran_detect_gen.dsp was renamed
to H5test_kind.f90.
Solution:
Platforms tested:
Compaq fortran 6.6 on windows XP.
Misc. update:
Use to generate H5f90i_gen.h and H5fortran_types.f90
Description:
Special project file for windows.
Solution:
Platforms tested:
MSVS 6.0 on windows XP.
Misc. update:
Use to generate H5f90i_gen.h and H5fortran_types.f90 on windows.
Description:
Special workspace for windows.
Solution:
Platforms tested:
MSVS 6.0 on windows XP.
Misc. update:
Use to generate H5fortran_detect.f90 in windows.
Description:
Special workspace for windows.
Solution:
Platforms tested:
MSVS 6.0 on windows XP.
Misc. update:
Use to generate H5fortran_detect.f90
Description:
Special project file on windows XP.
Solution:
Platforms tested:
MSVS 6.0 on windows XP.
Misc. update:
Use to generate H5fort_type_defines.h in windows.
Description:
Special project file for windows.
Solution:
Platforms tested:
MSVS 6.0 on windows XP.
Misc. update:
Special wrokspace for windows.
Description:
Use to generate H5fort_type_defines.h in windows.
Solution:
Platforms tested:
MSVS6.0 on windows XP.
Misc. update:
Adding windows workspace to simulate the fortran auto-type conversion procedures on linux.
Description:
Solution:
Platforms tested:
windows xp
Misc. update:
For windows support, remove all.zip from hdf5.
Description:
Add h5tinit project file into windows/misc/typegen/h5tinit
Solution:
Platforms tested:
MSVS 6.0 on windows xp.
Misc. update:
For windows support, remove all.zip from hdf5.
Description:
Add typegen workspace project file into windows/misc/typegen
Solution:
Platforms tested:
MSVS 6.0 on windows xp.
Misc. update:
