This commit teaches the FunctionTest to check variable scope behavior
when a subdirectory is added inside a function call. Any PARENT_SCOPE
sets in the subdirectory should affect only the function scope which
called add_subdirectory and not its parent scope.
The commit "Improve dynamic variable scope implementation" optimized
function scopes using an efficient parent scope pointer. However, the
parent scope used to initialize a new directory might not exist later
(like add_subdirectory called inside a function of the parent scope).
This caused CMake to crash when following the dangling pointer to the
original parent scope.
We fix the problem in this commit by always computing the closure of the
parent scope at directory initialization time so that no parent scope
pointer is needed. See issue #9538.
The cmProcess::Buffer class derives from std::vector. We were using
local variable 'data' in the GetLine method but this name shadowed a
member of vector with GNU. This renames it to 'text'.
-now supports specifying minimum required version
-now supports ruby 1.8 and 1.9
-uses find_package_handle_standard_args() now
-fix #6212 and using a lot of ideas from the file attached there
Alex
When we clear the buffer for an output pipe after returning the last
partial line (without a newline) we need to set the partial line range
to empty. Otherwise the buffer object is left in an inconsistent state.
This commit fixes cmCTestRunTest and cmProcess to more efficiently
handle child output. We now use the buffer for each child output pipe
to hold at most a partial line plus one new block of data at a time.
All complete lines are scanned in-place, and then only the partial line
at the end of the buffer is moved back to the beginning before appending
new data.
We also simplify the cmProcess interface by making GetNextOutputLine the
only method that needs to be called while the process is running. This
simplifies cmCTestRunTest so that CheckOutput can be called until it
returns false when the process is done.
The commit "Remove barely-used cmMakefile::AddCacheDefinition" removed
all but one use of the cmCacheManager method 'bool' overload. This
commit removes the other use and the entire method, thus reducing code
duplication.
The commit "Remove barely-used cmMakefile::AddCacheDefinition" broke
option() calls that pass a non-boolean default value. We restore the
old behavior by always coercing the value to 'ON' or 'OFF'.
The GNU compiler warns about possible operator precedence mistakes and
asks for explicit parentheses (-Wparentheses). We add the parentheses
to silence the warning. This also fixes one real logic error in the
find_package() implementation by correcting expression evaluation order.
The set(CACHE) and option() commands should always expose the cache
value. Previously we failed to expose the value when it was already set
if a local variable definition hid it. When set to NEW, this policy
tells the commands to always remove the local variable definition to
expose the cache value. See issue #9008.
The boolean overload of this method was used only to implement option().
We re-implement option() in terms of the main method and removes the
now-unused signature. This removes some duplicate code that had already
fallen behind on changes (it was not removing the local definition
instead of setting it).
Basically the code is now a copy of the one from the CodeBlocks generator,
maybe this could move into a common helper function somewhere:
-only insert GLOBAL targets from the toplevel directory
-don't insert the edit_cache target if it calls ccmake, since this doesn't
work in the output tab of Eclipse
-add the /fast targets
Alex
CMake now looks for a Fortran compiler matching any C or C++ compiler
already enabled. We test this by enabling C and C++ first in the
Fortran test, which is what user projects will likely do.
When CMAKE_Fortran_COMPILER and ENV{FC} are not defined CMake searches
for an available Fortran compiler. This commit teaches the search code
to look for compiler executables next to the C and C++ compilers if they
are already found. Furthermore, we bias the compiler executable name
preference order based on the vendor of the C and C++ compilers, which
increases the chance of finding a compatible compiler by default.
The CMakeExportBuildSettings and CMakeImportBuildSettings modules used
to export compiler paths and flags from one project and import them into
another. The import process would force the settings on the including
project.
Forcing settings helped long ago when compiler ABIs changed frequently
but is now just a nuisance. We've deemed the behavior harmful so this
commit simply removes it. The modules and macros now error out if
included or called from a project that requires CMake 2.8 or higher.