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:
Added a conversion of the H5config_fortran.h file to
H5pubconf_fortran.h so as to keep with the HDF5 format of using H5_
as a prefix for HAVE_* macros.
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
Fix
Description:
When doing a TRY_LINK, the compiler complained about lack of
parameters being passed to the function.
Solution:
Added the parameter it wants...
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:
Bug Fix
Description:
Parallel Fortran wasn't working on Modi4. The tests for parallel
MPI Fortran were failing to find MPI files.
Solution:
Changed the AC_TRY_FLINK() macro so that libraries are included
at the end of the link line so that unresolved symbols can be
found...
Platforms tested:
Modi4
Purpose:
Bug Fix
Description:
Hrm...When I was restoring the LDFLAGS variable after a failure, I
fergot to put a $ on the saved_LDFLAGS variable during the
assignment.
DOH!
Solution:
Added the $.
Platforms tested:
Modi4
Bug Fix
Description:
I wasn't testing if the Fortran compiler could actually do the MPI
compilation tests.
Solution:
Changed the configure script so that it uses Fortran 90 to test the
MPI compilation stuff instead of the MPI C compiler...
Platforms tested:
AIX and Linux
Purpose:
Bug Fix
Description:
The new way of detecting LibZ (just specifying the directory where
include/ and lib/ are) wasn't propagated down to the Fortran
directory.
Solution:
Added that code...
Platforms tested:
AIX and Linux
Purpose:
Bug Fix
Description:
The way we were generating Dependencies and .depend files was broken.
If the $srcdir or other macros began with a ".", then it would match
anything and cause problems since it would then overwrite the
beginning of the header file's path.
Solution:
Wrote a Perl script which can handle this type of weirdness better.
It's only used when the environment is a GNU one with a GCC
compiler...
Platforms tested:
Linux
Purpose:
Fix
Description:
Porting fixes from the 1.4 branch to the 1.5 branch. This fixes the
dependency problem in the testpar/ directory and also the problem
with module includes on the command line.
Purpose:
Bug Fix
Description:
In order for libtool to point to the place zlib lives (when
specified) it needs to add that flag to the LDFLAGS macro. However,
since we're getting this information from the top-level configure,
it's cached. Thus, we don't check for it and the -L flag doesn't get
included into the LDFLAGS macro.
Solution:
Remove the cached value so that the Fortran configure will always
check for zlib even if it's found by the top-level configure.
Platforms tested:
Kelgia
Purpose:
Bug bypass
Description:
Fortran configure checks flags where to find F90 modules in the
order "M", "I" and "p". On IBM SP "M" is a reserved flag, configure
does not understand compiler's warning and uses it to specify
module directories. Then tests and examples compilation fails since
module directory is not specified correctly on the compilation line.
Solution:
Changed the order of flags to be "I", "M", "p", so configure on IBM SP
finds the correct flag first.
Platforms tested:
NERSC IBM SP (gseaborg)
Portability changes
Description:
Very quick port to Compaq (nee DEC) Alpha OSF5.
Solution:
Added a new "dec-osf5.x" configuration file and changed configure.in
to look for it.
The local test machine is now passing all the tests, except I can't get
the "-L<path>" stuff to work, so tools which depend on the HDF4 library
around tested.
Platforms tested:
Compaq Alpha 5.1 (compaq.ncsa.uiuc.edu)
Bug Fix
Description:
Create a Makefile in the testpar/ directory only if PARALLEL is
enabled.
Solution:
Set a macro to the testpar/Makefile for the generation script.
Bug Fix
Description:
Small bug fix to the acsite.m4 stuff. We should check if the Fortran
9X compiler was found instead of the CC compiler.
Solution:
Changed CC to F9X macro.
Platforms tested:
Linux
Install Fix
Description:
Fortran modules need to be installed.
Solution:
I check for the extension modules are created with and use that
during the install...
Platforms tested:
Linux
Attempted Bug Fix
Description:
Some machines (Cray T3E, need you ask?) use the ``-p'' flag for
enabling double precision. This breaks our Fortran interface.
Solution:
Put this test last. However, the T3E apparently doesn't need
modules, so we may have to resort to a better "fix" than this
in the future.
Platforms tested:
T3E
Bug Fix
Description:
T3E and J90 were complaining about not being able to make for
ADD_PARALLEL_FILES.
Solution:
Somehow the make on these machines must have been weirded out by
the funky pattern matching/replacement that's being done and
couldn't handle a null macro. I now assign "no" to the macro
explicitly
Platforms tested:
T3E
Buglet fix
Description:
Was removing the confdefs.h header which was needed during
Makefile generation.
Solution:
Stopped doing that.
Platforms tested:
Linux
Buglet fix...
Description:
When configuring, configure would complain about there not being
a confdefs.h file.
Solution:
Added a src/H5config.h file which configure can generate. This
can be used for configure stuff later, but is empty now.
Platforms tested:
Linux
Bug Fix
Description:
Sed was complaining about "filename expected" when trying to
generate the .in files. The problem stemmed from the script sed
was generating in the conftest.s1 file. It needed the DEPEND
filename which wasn't being set.
Solution:
Fixed so that we check if DEPEND is zero before trying to set if
(if not using a GNU make program) instead of testing if DEPEND
has a value in it...I copied this incorrectly from the main
library's configure.in file...my bad.
Platforms tested:
T3E
Bug Fix
Description:
I was relying on the PARALLEL macro to be "yes" or "no" all the
time. This isn't the case.
Solution:
Created the ADD_PARALLEL_FILES macro to do just this.
Platforms tested:
Modi4
Bug Fix
Description:
The "fix" for search paths was wrong. It would try to recompute
the SEARCH macro at the end.
Solution:
Stopped it from doing that if the $SEARCH macro has a value. One
question, will fortran always be built from the top directory?
Platforms tested:
Modi4
Bug Fix
Description:
When running configure on subdirectories (like fortran/), looking
up how make implements SEARCHes failed.
Solution:
Exporting the SEARCH macro so that subdirectories don't have to
look for it.
Platforms tested:
Modi4.
Adding the Fortran interface to the HDF5 library
Description:
Fortran is now a subdirectory of the HDF5 library tree.
Platforms tested:
Solaris and IRIX (O2K)
