In Visual Studio project files we pass compiler flags to the whole
target based on the linker language, which works for MS tools and
combinations of C and C++. For the Intel Fortran plugin though the
generated .vfproj files should never contain C or C++ options.
We generate .vfproj files only for targets consisting only of Fortran
code. Now that the linker language is computed transitively through
linking it is possible that the linker language is C++ for an otherwise
Fortran-only project. This commit forces Fortran as the linker language
for the purpose of specifying target-wide flags in .vfproj files.
See issue #9719.
The commit "Avoid non-root copies of root-only targets" moved the check
for root-only targets into cmGlobalGenerator::GetTargetSets to avoid
adding multiple ALL_BUILD targets to the "original" target set. This
approach did not work for ZERO_CHECK targets though because those are
pulled in by dependency analysis.
Instead we eliminate duplicate ZERO_CHECK targets altogether and refer
to a single one from all solution files. This cleans up VS 10 project
file references to ZERO_CHECK targets anyway.
To enable this test, the option TEST_KDE4_STABLE_BRANCH must be switched on.
It can only be switched on if CMAKE_RUN_LONG_TESTS is ON.
Then the test will only be added if Qt >= 4.5 can be found, Perl can be
found and ZLIB can be found.
Alex
although #9621 did not happen anymore with cmake 2.8.0, probably because
GET_PROPERTY(... GLOBAL ...) now makes the result variable empty instead of
simply not touching it, using FUNCTION() instead of MACRO() makes sure that
the _EnabledFeatures variables is always empty before the GET_PROPERTY()
call (and does not still have the old value from the previous call)
Alex
1. Add STATUS output "Could NOT find Boost" if boost is not found
which brings FindBoost closer in behavior to most CMake find modules.
2. Add an option: Boost_DETAILED_FAILURE_MSG to output
Boost_ERROR_REASON on a non-REQUIRED find if this
is desired by the developer. This is done because the error messages
are rather long and software with optional Boost dependencies might
not like them showing up by default, especially since this wasn't done
before.
3. Add mention of Boost_ADDITIONAL_VERSIONS close to top
of file since this seems to be the most common problem brought
up on the mailing list (maybe people will notice it there)
4. Added additional check for intel compiler which probably isn't
necessary but ultimately should be cleaner if CMAKE_CXX_COMPILER_ID
sticks around.
5. Added my name to the Copyright list
We revert commit "Create CMake Policy CMP0015 to fix set(CACHE)" because
the NEW behavior of the policy breaks a valid use case:
# CMakeLists.txt
option(BUILD_SHARED_LIBS "..." ON)
add_library(mylib ...)
set(BUILD_SHARED_LIBS OFF) # we want only mylib to be shared
add_subdirectory(ThirdParty)
# ThirdParty/CMakeLists.txt
option(BUILD_SHARED_LIBS "..." ON)
# uh, oh, with NEW behavior this dir uses shared libs!!!
We'll re-introduce the policy later with a different change in behavior
to resolve the motivating case, which was more subtle but less common.
See issue #9008.
The commit "Really fix color check for dependency scanning" disabled
color unless "make COLOR=ON" is specified. This restores the previous
default behavior when CMAKE_COLOR_MAKEFILE is ON while retaining the
previous commit's fix. See issue #9680.
The commit "Fix color check for dependency scanning" was meant to
disable color if CMAKE_COLOR_MAKEFILE was off. It did remove use of the
activation option '--color' but it failed to make the default false when
the option was missing. This commit corrects that. See issue #9680.
Zach Mullen
Philip Lowman
KWSys Robot
Brad King
Alexander Neundorf
Marcus Hanwell
David Cole
Bill Hoffman