The function _Boost_MISSING_DEPENDENCIES will look at the
user-supplied component list, check the dependency
information for each component using
_Boost_COMPONENT_DEPENDENCIES, and will add any missing
dependencies to the component list. This ensures that
all required components will be searched for.
The function _Boost_COMPONENT_DEPENDENCIES is used to query the
library dependencies for a given component for a given version of
Boost. This covers Boost releases from 1.33 to 1.59, using the
information generated by Utilities/Scripts/BoostScanDeps.cmake.
These cache entries introduced by commit 892b854f (FindBoost: Search for
debug and release libraries separately, 2015-01-26) should be marked as
advanced just as Boost_LIBRARY_DIR was. Also their _LAST values should
be tracked so changes can be detected reliably. Both of these are
handled by code looking in _Boost_VARS_LIB for a list of relevant
variables. Fix construction of this list that was broken by the above
commit.
Reported-by: Sylvain Joubert <joubert.sy@gmail.com>
Green Hills MULTI is an IDE for embedded real-time systems. The IDE's
product page can be found here:
http://www.ghs.com/products/MULTI_IDE.html
It supports cross compiling on ARM, Intel x86, and other architectures
with various operating systems. The IDE exists on Linux and Windows
host systems, but CMake will currently only generate the project files
on Windows host systems.
When using CMAKE_FIND_ROOT_PATH, FindBoost is able to find the first
component and cache the full path of the directory in Boost_LIBRARY_DIR
so that all components are looked for in same directory. The issue was
that, when looking for the other components, Boost_LIBRARY_DIR was
re-rooted against CMAKE_FIND_ROOT_PATH even though it was already a path
on the host. This change fixes this by disabling the re-rooting in the
find_library call when using Boost_LIBRARY_DIR as a hint.
See http://www.cmake.org/pipermail/cmake-developers/2014-October/011670.html
When testing CMAKE_CXX_COMPILER[_ID] values with if(MATCHES) or
if(STREQUAL), do not explicitly dereference or quote the variable.
We want if() to auto-dereference the variable and not its value.
The matches have already been calculated and can simply be taken from
CMAKE_MATCH_n variables. This avoids multiple compilations of the same or very
similar regular expressions.
When building boost with an alternate namespace the libraries generated
will have a different naming convention. This is often done to ensure
no symbol conflicts with external libraries built against a different
version of boost. If the namespace used is "myprivateboost::" instead
of "boost::" then the libraries built will be named myprivateboost_foo
instead of boost_foo. Add an option to specify a custom namespace used
to alter the library names that get searched for.
Some distributions place boost_mpi next to the MPI libraries against
which it was built instead of next to the other Boost libraries. If
find_package(MPI) has already been run prior to find_package(Boost) then
MPI_CXX_LIBRARIES or MPI_C_LIBRARIES may be set to the location of the
MPI libraries. Teach FindBoost.cmake to look there for boost_mpi and
boost_mpi_python after looking next to the other Boost libraries but
not consider the location to be Boost_LIBRARY_DIR.
When Boost_USE_STATIC_LIBS is ON we may complain that Boost libraries
cannot be found even when shared libraries are present. Update the
error message to tell the user explicitly that we want static libraries.
Suggested-by: Laurence R. McGlashan <laurence.mcglashan@gmail.com>
In commit 5b9149e0 (FindBoost: Overhaul caching and search repeat
behavior, 2012-09-24) we refactored the internal library search to use a
_Boost_FIND_LIBRARY macro to wrap around find_library calls. However,
CMake macros re-process escape sequences when evaluating calls inside
the macro after substituting placeholders (a historical bug). In order
to avoid escape sequences, convert backslashes to forward slashes before
passing arguments to the _Boost_FIND_LIBRARY macro.
Write new documentation for this module. Ensure that it formats
correctly in "cmake --help-module FindBoost" output. Show the basic
form of calling find_package(Boost). Document all result variables,
input variables, and cache variables appropriately grouped together.
Explain the search process and how it re-runs when changes are made.
Explain the difference between finding headers/libraries versus finding
a "Boost CMake" package configuraiton file.
Drop the emphasis on Boost_ADDITIONAL_VERSIONS because the
implementation should predict most future versions instead.
Construct an initial Boost_FOUND value immediately after searching for
Boost_INCLUDE_DIR. Base the result only on whether header files for the
requested version were found. Then after searching for component
libraries update Boost_FOUND based on whether all requested components
were found.
Construct the value from scratch based on the component library list.
Avoid accumulating values from repeated find_package(Boost) calls.
If Boost is not found, Boost_LIBRARIES should be empty.
Overhaul the implementation as follows:
(1) Do not cache result variables such as Boost_VERSION,
Boost_LIB_VERSION, Boost_LIBRARY_DIRS, Boost_${COMPONENT}_FOUND,
Boost_${COMPONENT}_LIBRARY, or Boost_LIB_DIAGNOSTIC_DEFINITIONS that are
derived uniquely from other search results. The user should not edit
them anyway.
(2) Add cache value Boost_LIBRARY_DIR to hold the single directory
expected to contain all libraries. Once one library is found, search
only that directory for other libraries.
(3) Use the find_library NAMES_PER_DIR option to consider all possible
library names at the same time.
(4) Collect all documented input and cache variables and detect when
they have been changed by the user. Discard prior search results that
may have been influenced by the changes and search for them again.
Environment variables are not expected to be persistent so use them only
as hints and do not consider changes to them to be meaningful.
The CMake find_path command looks under the proper "Program Files"
directories on Windows with any of the provided PATH_SUFFIXES. This is
simpler and more robust than directly reading ENV{ProgramFiles}. Once
Boost_INCLUDE_DIR has been located we already look next to it for the lib
directory anyway, so we do not need special help to find Boost libraries
under "Program Files".
Instead of reading the whole file using file(READ) and later matching on the
whole file use file(STRINGS ... REGEX) to get only those lines we are
interested in at all. This will make the list much smaller (good for debugging)
and also the regular expressions will need to match on much smaller strings.
Also unset the content variables once they are not used anymore.
Ancient versions of CMake required else(), endif(), and similar block
termination commands to have arguments matching the command starting the
block. This is no longer the preferred style.
Run the following shell code:
for c in else endif endforeach endfunction endmacro endwhile; do
echo 's/\b'"$c"'\(\s*\)(.\+)/'"$c"'\1()/'
done >convert.sed &&
git ls-files -z -- bootstrap '*.cmake' '*.cmake.in' '*CMakeLists.txt' |
egrep -z -v '^(Utilities/cm|Source/kwsys/)' |
egrep -z -v 'Tests/CMakeTests/While-Endwhile-' |
xargs -0 sed -i -f convert.sed &&
rm convert.sed
Fixes a problem where when specifying a version number without the REQUIRED
parameter, Boost_FOUND would be true on the first configure but false on
subsequent configures.
FindBoost now attempts to find Boost using find_package(Boost NO_MODULE)
before it does a module mode search.
User can now set any of these to Boost's install prefix to detect it in module
or config mode:
- Boost_DIR for consistency with other CMake modules
- BOOST_ROOT or BOOSTROOT for adherence to boost convention
Workaround an issue where users wanted to use Boost_LIBRARIES with the
install() command and debug/optimized keywords were interfering. Now
debug/optimized keywords are removed if the release & debug library
are the same.
