This way the name of the searched package can be accessed in find-modules,
config-files and more importantly in generated target export files.
This is now used when a target export file detects that a required
target does not exist.
Alex
Before, cmExportFileGenerator::ComplainAboutMissingTarget() was a virtual
function which had to be implemented in the subclasses. It is not
anymore. Instead, there is now a virtual function
HandleMissingTargets(), which is implemented in the two subclasses.
This makes e.g. dealing correctly with APPEND mode easier.
Alex
Move it out of the condition that also accepts MinGW/MSYS.
Teach the test to allow the Intel for Windows compiler but
do not verify the results because the compiler does not
seem to write PDB output in all cases.
083de7e Process generator expressions in the COMPILE_DEFINITIONS target property.
08cb4fa Process generator expressions in the INCLUDE_DIRECTORIES property.
0ef091d Early return if there is no target.
eb250cd Add a self-reference check for target properties.
7e80747 Add API to check that dependent target properties form a DAG.
239ac84 Add a generator expression for target properties.
e028381 Extend the generator expression language with more logic.
b8e61d6 Refactor GetCompileDefinitions a bit.
2c2b25b Return a std::string from GetCompileDefinitions.
b7e48e0 Add an AppendDefines std::string overload.
9a16087 Convert paths in INCLUDE_DIRECTORIES property to Unix slashes.
4557c8d Don't prepend a path before generator expressions in include_directories.
c6abc41 Add include guard for cmGeneratorExpression.
0ff4e3f Port remaining code to GetCompileDefinitions().
f178d53 Fix indentation in the code blocks generator.
Now, if an imported target depends on a library which must come
from some other export set, cmake generates a check which errors
out if that target does not exist. I guess instead of completely
erroring out it would be better to only make the find_package() fail.
Alex
If a target is exported, and a library it depends on is not part
of the same export set, before this patch cmake errored out.
With this patch, it now checks whether the missing target
is exported somewhere else exactly once, and accepts in this
case (because then it can determine the namespace for the
missing target and use this).
Alex
If a config-file sets <package>_FOUND to FALSE, it can now give a reason
using the variable <package>_NOT_FOUND_MESSAGE, which is used by cmFindPackage
and FPHSA.
Alex
The remainder of this method depends on the target existing (otherwise
the includes container would be empty), so make the code a little more
readable.
Prevent constructs like:
... INCLUDE_DIRECTORIES "$<TARGET_PROPERTY:INCLUDE_DIRECTORIES>"
Indirect self-references (cycles) are also prevented here, but
indirect generator expression references of any kind are not
possible yet anyway.
There are two overloads, so that it can use the operational
target when a target property is being evaluated, and a target
can alternatively be specified by name.
At this point, the generators don't chain. That comes later.
Generator expressions for comparing strings, evaluating
strings as booleans, and for creating literal right-angle-brackets
and commas are added. Those may be needed in some cases
where they appear in literals.
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".
Since FPHSA is called for multiple compiler languages with "MPI_${lang}"
rather than just "MPI", make sure variables for controlling QUIET,
REQUIRED and VERSION are propagated with names prefixed by MPI_${lang}
as well, rather than just MPI.
The find_package call sets up the values of MPI_FIND_REQUIRED and friends,
but these calls to FPHSA need MPI_${lang}_FIND_REQUIRED and friends in
order to function as intended.