Update
Description:
Changed so that the Fortran and C++ configures are named "HDF5
Fortran" and "HDF5 C++" resp. instead of just "HDF5.
Solution:
Add an extra parameter to the subroutine which generates the new
configure.in files.
Platforms tested:
Linux
Update
Description:
Updated the h5vers script to automatically update the configure.in
files so that they reflect the correct version in the AC_INIT line.
Platforms tested:
Linux
Update
Description:
Updated the way we used the AC_INIT macros so that it's current to
the new standard way and not deprecated anymore.
Also, added a test for some functions during parallel Fortran
configure. This required the creation of an H5config_fortran.h file
so that we can test for these...
Platforms tested:
Elena is going to test the changes to the fortran after she checks in
her other code. I will test on SDSC machines after getting her code.
The other changes were tested on Linux.
Feature Update
Description:
Modified the AC_OUTPUT macro to coincide with the now-standard
way of doing things. I.e., you put all of the files you want to
generate into the AC_CONFIG_FILES macro and invode AC_OUTPUT with
no parameters.
Platforms tested:
Linux
Autotools Update
Description:
I've updated autoconf, automake, and libtool to the latest/greatest
versions; 2.53, 1.6, and 1.4.2 resp.
Many changes come with the new versions:
- ltconfig is no longer used
- acconfig.h is no longer used (#define values are declared with
the macro)
- regeneration of all of the aclocal.m4, configure, and
H5config.h.in files.
- new config.{guess,sub} files
- new ltmain.sh file
Platforms tested:
AIX (blue), and Linux
Purpose:
Code cleanup
Description:
DataType::convert: changed the 'nelmts' parameter from size_t to
hsize_t according to hdf5 library change.
Platforms tested:
SunOS 5.7 (arabica)
Linux 6.2 (eirene)
Purpose:
Small bug fixing
Description:
Replaced NULL by 0 for initializing or passing null "string".
The problem showed up on platinum.
Platforms tested:
SunOS 5.7 (arabica)
Linux 6.2 (eirene)
IA-32 Linux Cluster (platinum)
Purpose:
Adding new member function
Description:
Added PropList::copyProp according to the new api H5Pcopy_prop
in the C library. I'm still working on adding more tests so
test for this will be added as well.
Platforms tested:
SunOS 5.7 (arabica)
Linux 6.2 (eirene)
FreeBSD 4.4 (sleipnir)
DLL accommodation
Description:
In the inline constructor below:
DSetCreatPropList() : PropList( H5P_DATASET_CREATE) {}
H5P_DATASET_CREATE causes the famous "unresolved symbol" error
when building the Release version of dsets_cpp with DLL.
H5P_DATASET_CREATE uses H5P_CLS_DATASET_CREATE_g, which is
imported from hdf5dll. The inline constructor used in dsets.cpp
causes the use of H5P_CLS_DATASET_CREATE_g, which is then
considered undefined because dsets_cppdll is not using hdf5dll.
This only occurs in the Release version because the Debug build
disables inline.
Solution:
Made the affected constructor not inlined, i.e., its implementation
went in the cpp file.
Note that this problem does not occur in 1.4 branch because
H5P_DATASET_CREATE was defined differently, i.e., did not involve
external storage.
Platforms tested:
SunOS 5.7 (arabica)
Linux 6.2 (eirene)
Windows 2000
Purpose:
Bug Fix
Description:
C++ examples weren't being removed.
Solution:
We were trying to remove something called "EXAMPLE_DOCS", but we
needed to remove "EXAMPLE_PROGS" instead.
Platforms tested:
Linux
Bug Fix
Description:
The make uninstall-examples wasn't working if fortran or C++ was
built.
Solution:
Added uninstall-examples to the Makefile.
Platforms tested:
Linux
Purpose:
Adding support for dll
Description:
Added __DLLCPP__ to all public classes and templates.
Added #include "H5Include.h" to H5RefCounter.cpp because of the
use of DLLCPP in .h file and it needs the following chain:
H5Include.h/hdf5.h/H5public.h/H5api_adpt.h
Added #pragma warning(disable: 4251) to H5Exception.h to eliminate
this warning on private data members of type 'string.' This
occurs because 'string' is not yet instantiated at compilation
time; however, since the class is exported, the warning is
harmless.
Changed this member function's parameter to be passed as reference.
from:
void CompType::insertMember( const string name,...
to:
void CompType::insertMember( const string& name,...
Platforms tested:
Linux 6.2 (eirene)
Windows 2000
Purpose:
Fix fix
Description:
Moved Binh-Minh's fix of the lack of support for C++ in libtool by
adding the DEFAULT_LIBS macro into the configure.in and
config/commence.in files.
Solution:
Put it into the configure.in and commence.in files. Reran autoconf.
Purpose:
Improvement
Description:
Using LIBS for c++ default library resulted in the library showed up
in two many places.
Solution:
Added new macro DEFAULT_LIBS to specify default library for the
C++ API tests
Platforms tested:
IRIX64 (modi4)
Purpose:
Added platform support
Description:
The current libtool doesn't fully support C++ yet, so until it
does, the default libraries have to be manually specify.
Some minor cleanups needed.
Solution:
Added DEFAULT_LIBS=@DEFAULT_LIBS@ to use new macro for default library.
Added $(DEFAULT_LIBS) to link lines.
Removed inappropriate comments.
Platforms tested:
IRIX64 (modi4)
I'll check out again to make sure I haven't broken anything else.
Purpose:
Added platform support
Description:
The current libtool doesn't fully support C++ yet, so until it
does, the default libraries have to be manually specify.
Some minor cleanups needed.
Solution:
Added DEFAULT_LIBS=@DEFAULT_LIBS@ to use new macro for default library
Added $(DEFAULT_LIBS) to link lines
Removed inappropriate comments, and this extra set, it occurs twice:
## These are our main targets. They should be listed in the order to be
## executed, generally most specific tests to least specific tests.
RUNTEST=$(LT_RUN)
although I'm not sure if it even should be there, so I should leave
it for Bill.
Platforms tested:
IRIX64 (modi4)
I'll check out again to make sure I haven't broken anything else.
Purpose:
Added platform support
Description:
Added new macro DEFAULT_LIBS to specify default library for the
C++ API tests
Platforms tested:
IRIX 6.5 (modi4)
Purpose:
Adding new supported platform
Description:
Added this config file for modi4. Note that, when libtool v1.5
is released and we start using it, the default library libCio can
and should be removed from LIBS. It is there now because previous
versions of libtool do not fully support c++ yet and default
libraries must be manually added to the link line.
Platforms tested:
IRIX64 6.5 (modi4)
Purpose:
Bug fix
Description:
In several if statements, '>' was used in place of '<='. This
caused exceptions thrown inappropriately. Replaced '>' by '<='
where applicable.
Platforms tested:
SunOS 5.7 (arabica)
Windows 98
Purpose:
Feature Rollback
Description:
Shared C++ libraries aren't working on all platforms (read: Arabica).
We need to switch to the old method until we can sort this out.
Solution:
Re-add the "-static" flag to the library creation lines.
Purpose:
Bug Fix
Description:
There were weird "throw()"s which were being placed into the
configure script. Some C++ compilers were barfing on this syntax
(which was akin to "extern int exit(int) throw ();" wonder why?).
Solution:
Ran a different autoconf on the configure file which I'd downloaded
from ftp.gnu.org. It doesn't have those "throw()"s anymore
Platforms tested:
Linux
Purpose:
Bug Fix
Description:
Shared libraries weren't being built for C++.
Solution:
Removed the -static flag from the libtool compile line. This allows
both shared and static libraries to be built instead of just static
ones. After talking with Quincey and Binh-Minh, there shouldn't be
any reason for C++ to be built static only.
Platforms tested:
Linux
Purpose:
Removing warnings
Description:
H5IdComponent::operator= shouldn't be virtual because the subclass'
operator= have different type for the rhs argument. Removed virtual.
Platforms tested:
SunOS 5.7 (arabica)
Linux 6.2 (eirene)
Purpose:
Bug fixing
Description:
H5IdComponent::operator= shouldn't be virtual because the subclass'
operator= have different type for the rhs argument. Removed virtual
Platforms tested:
SunOS 5.7 (arabica)
IRIX64 (modi4) - only tested that the warnings went away, still working
on other configuration problems.
Purpose:
Bug Fix
Description & Solution:
In the test for "namespace", we needed to include the "iostream"
header file to remove errors for strict compilers who need iostream
for namespaces. I moved the test for namespace to after the test for
"old header filenames" to make sure that I'm #including the correct
iostream ("iostream" or "iostream.h").
Platforms tested:
Linux
Code cleanup
Description:
Property that H5P(g|s)et_hyper_cache uses is no longer in use inside the
library.
Solution:
Removed H5P(g|s)et_hyper_cache API functions, except when backward
compatibility is turned on. When backward compatibility is turned on,
the property is defined by the library, but unused internally.
Platforms tested:
FreeBSD 4.4 (sleipnir)
Backward Compatibility Fix
Description:
One of H5P[gs]et_buffer's parameters changed between v1.4 and the
development branch.
Solution:
Added v1.4 compat stuff around H5P[gs]et_buffer implementation and testing
to allow v1.4.x users to continue to use their source code without
modification.
These changes are for everything except the FORTRAN wrappers - I spoke with
Elena and she will make the FORTRAN wrapper changes.
Platforms tested:
FreeBSD 4.4 (hawkwind)
Backward Compatibility Fix
Description:
One of H5P[gs]et_sym_k's parameters changed between v1.4 and the development
branch.
Solution:
Added v1.4 compat stuff around H5P[gs]et_sym_k implementation and testing
to allow v1.4.x users to continue to use their source code without
modification.
These changes are for everything except the FORTRAN wrappers - I spoke with
Elena and she will make the FORTRAN wrapper changes.
Platforms tested:
FreeBSD 4.4 (hawkwind)
Backward Compatibility Fix
Description:
One of H5P[gs]et_cache's parameters changed between v1.4 and the development
branch.
Solution:
Added v1.4 compat stuff around H5P[gs]et_cache implementation and testing
to allow v1.4.x users to continue to use their source code without
modification.
These changes are for everything except the FORTRAN wrappers - I spoke with
Elena and she will make the FORTRAN wrapper changes.
Platforms tested:
FreeBSD 4.4 (hawkwind)
Purpose:
Eliminated warnings
Description:
On IRIX and Windows 98, if a function, that returns a value, throws
an exception in "else" statement, the compiler still complains that
the function doesn't return a value.
Solution:
Replaced:
if (something valid)
return a value
else
throw an exception
with:
if (something invalid)
throw an exception
return a value
Platforms tested:
Windows 98
SunOS 5.7 (arabica)
Linux 6.2 (eirene)
IRIX64 (modi4) - only tested that the warnings went away, still working
on other configuration problems.
Purpose:
Bug fix
Description:
Add the overloaded member function Attribute::getName to return
the attribute name's length as in C API. This functionality was
missing. Note that the current getName that returns "string"
is not removed, for different way of using getName.
Platforms tested:
SunOS 5.7 (arabica)
Windows 98
Purpose:
Fixing found bug
Description:
A data file cannot be removed because the corresponding H5File object
is still in existence, which means the data file is still opened.
Solution:
Moved h5_cleanup to outside of the try block so that the H5File object
will go out of scope and be destroyed before h5_cleanup attempts to
remove the corresponding data file.
Platforms tested:
SunOS 5.7 (arabica)
Windows 98
Purpose:
Switch from old property list to new generic property list.
Description:
Changed C++ according to the new generic property list.
Platforms tested:
FreeBSD, SunOS 5.7.
Purpose:
Bug fixing
Description:
+ added operator= to PredType
+ removed 'using namespace std' from H5RefCounter.cpp because it's not
used and leaving it there requires #include some standard header file
+ added 'using namespace std' in H5Exception.cpp
Platforms tested:
SunOS 5.7 (arabica)
Windows 98
Kludge
Description:
Since we're only about halfway through converting the internal use of
property lists from the "old way" to the generic property lists, we turned
off snapshots to avoid exposing lots of API changes to users, until the
APIs settled down.
Getting the snapshots rolling again seems to have become a priority, so
some changes are going to have to be made now that were going to be
postponed until we were completely finished with the conversion. This
requires that the old API functions be able to deal with both the old
and new property lists smoothly.
Solution:
Kludge together the property list code so that they can transparently handle
dealing with both the old and new property lists
Platforms tested:
FreeBSD 4.4 (hawkwind)
Purpose:
Feature Add
Description:
Added "install-example" and "install-all" to the Makefile system.
The behaviour of the "make install*" options:
make install - Installs binaries, libraries, include
files, and example programs.
make install-examples - Installs only the example programs.
The directories are:
${prefix}/doc/hdf5/examples/{c,c++,fortran}
make install-all - Install the binaries, libraries, include
files, example programs, and
documentation. The whole kit-n'-caboodle.
make uninstall-examples - Get rid of those example files (but not
the ${prefix}/doc/hdf5/examples/...
directories)
There's a new bin/ program which helps create directories which are
deeply nested called "mkdirs". It's a simple shell script.
Platforms tested:
Linux
Code cleanup
Description:
Changed prototype for the buffer in Attribute::write from "void *"
to "const void *"
Platforms tested:
FreeBSD 4.4 (hawkwind)
SunOS 5.7 (arabica)
Linux 6.2 (eirene)
Code cleanup (sorta)
Description:
When the first versions of the HDF5 library were designed, I remembered
vividly the difficulties of porting code from a 32-bit platform to a 16-bit
platform and asked that people use intn & uintn instead of int & unsigned
int, respectively. However, in hindsight, this was overkill and
unnecessary since we weren't going to be porting the HDF5 library to
16-bit architectures.
Currently, the extra uintn & intn typedefs are causing problems for users
who'd like to include both the HDF5 and HDF4 header files in one source
module (like Kent's h4toh5 library).
Solution:
Changed the uintn & intn's to unsigned and int's respectively.
Platforms tested:
FreeBSD 4.4 (hawkwind)
