100b22e6c2
* Use case-inseneitive comparison for headers HTTP headers should be case-insensitive. Use case-insensitive string comparisons when working with HTTP header responses to ensure compatibility. * Revert "Use case-inseneitive comparison for headers" This reverts commit a02f591723506b62b7208449be6eef7122120398 * Ignore case when searching HTTP header responses Looking up the Content-Length in the header returned by S3 storage endpoints should ignore case. To guarantee portability implement a function for case-insensitive string search, because it is non-standard. * Add an _ after H5 for the strcasestr implementation It is a private function and should sport that underscore. * Remove author comment from the doc comment * Use search function defined by system if available Check whether the system provides a function implementing case insensitive string searches. Only use the custom implementation if the system does not provide the functionality. * Add tests for case-insensitive search Basic tests: - Search for empty string - Search with exact match - Search with case-insensitive match - search with no match * Enforce clang-format style Some variable definitions in the th5_system tests did not conform to clang-format's expectations. Updated the offending lines. * Correct comment describing test case * Added some spaces to please clang-format * Ignore discarding const Ask the compiler to ignore discarding the const when retunring a match from H5_strcasestr Co-authored-by: Frank Berghaus <frank.berghaus@mpcdf.mpg.de> |
||
|---|---|---|
| .. | ||
| clang-warnings | ||
| cmake | ||
| gnu-warnings | ||
| intel-warnings | ||
| sanitizer | ||
| site-specific | ||
| toolchain | ||
| apple | ||
| BlankForm | ||
| cce-fflags | ||
| cce-flags | ||
| clang-cxxflags | ||
| clang-flags | ||
| commence.am | ||
| conclude_fc.am | ||
| conclude.am | ||
| cygwin | ||
| examples.am | ||
| freebsd | ||
| gnu-cxxflags | ||
| gnu-fflags | ||
| gnu-flags | ||
| ibm-aix | ||
| ibm-flags | ||
| intel-cxxflags | ||
| intel-fflags | ||
| intel-flags | ||
| libhdf5.fpc.in | ||
| libhdf5.pc.in | ||
| linux-gnu | ||
| linux-gnuaout | ||
| linux-gnueabihf | ||
| linux-gnulibc1 | ||
| linux-gnulibc2 | ||
| lt_vers.am | ||
| Makefile.am.blank | ||
| netbsd | ||
| pgi-cxxflags | ||
| pgi-fflags | ||
| pgi-flags | ||
| README.md | ||
| solaris | ||
The config directory
Intro
HDF5 can be configured using both the GNU Autotools and CMake. We try to keep
them in sync, but you can expect minor differences to crop up. Please create
a GitHub issue for any differences noted. Note that with the Autotools, we
do NOT check generated files into GitHub until release time, so you will
need to generate configure, Makefile.in(s), etc. via autogen.sh in the
project root if you want to build with that system.
Configuration information for the HDF5 library and tools is (unfortunately)
spread across the repository. Basic library configuration will generally
be found in configure.ac (Autotools) and the root's CMakeLists.txt (CMake).
Each subdirectory of the project also has its own Makefile.am or CMake build
and test files.
This directory contains a few important things:
- Autotools OS- and compiler-specific configuration
- CMake support files (in
cmake) - Warning files shared between the two systems (in
*-warningsdirectories) - CMake toolchain files (in
toolchain) - CMake sanitizer files (in
sanitizer)
CMake will be documented elsewhere. This document focuses on the Autotools files and the shared warning files.
Autotools
An Autotools build will first use $host_cpu, $host_os, etc. to try to find a
suitable platform file in config to source and start checking compilers. The
code that does this is in configure.ac (search for host_os). For example,
MacOS will source the apple file and FreeBSD will source the freebsd file.
There are a bunch of Linux files, but they all eventually invoke
linux-gnulibc1.
If you dig into one of these files, the way that they check for compilers is
rather crude. Each OS script will simply source the various C, C++, and
Fortran compiler files that are listed inside. Each compiler file checks
the designated compiler's version output to see if there's a match, and if so,
the flag processing proceeds, and a variable like cc_flags_set will be set
at the end.
In case it's not obvious, the C files end in -flags, C++ in -cxxflags, and
Fortran in -fflags.
When a compiler matches, the script will attempt to set the CFLAGS, etc.
variables based on the platform and compiler's properties. There are typically
a large number of flag categories (e.g., DEBUG_OPT_CFLAGS) that are
conditionally appended to the canonical variables, like AM_FLAGS, by the
remainder of the configure script.
For the major compilers, like Clang and gcc, there will be a section at the
end where we append version-specific flags, mainly for warnings. These are
imported via a function in the script (load_gnu_arguments() for gcc). See
below for more detail.
Warnings files
Keeping the Autotools and CMake build files in sync has always been a bit of a struggle. One way that we help to ensure that the same flags are used in each build system is to import the warnings settings from text files that are maintained separately from the Autotools and CMake build files. We like to configure the compiler to be as crabby as possible so as to catch subtle bugs, so there are a LOT of warning flags for popular compilers like Clang and gcc.
We've located these files in config/*-warnings directories. Each file
represents a compiler version and contains the warning flags we set, one to a
line. Lines that start with # are considered comment lines. You'll also see
developer and no-developer flavors of compiler version files. The former
corresponds to "developer flags" that are usually either only semi-useful and/or
generate a lot of (usually unfixable) noise. The latter corresponds to things
that we want to ensure do NOT appear in non-developer builds of the library.
These might involve a different level setting (-Wfoo=x) or something that
gets incorporated in a "conglomerate" flag like -Wextra so we need to set
-Wno-foo in non-developer builds. Developer warnings can be turned on
via a configure option. You will also sometimes see error files. Those are
files that include warnings that will be considered errors if you have enabled
the "warnings as errors" configure option set. Now that the library is largely
warning-free, these are less useful than in the past as you can now just set
-Werror directly in many cases (our configure script is smart about not running
configure checks with -Werror).
For anyone interested, we are always interested in improving both the OS and compiler files, so pull requests for those are always welcome, especially for platforms we don't have routine access to. If you are a compiler or platform expert/aficionado, please help us out!