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.
Visual Studio 10 uses MSBuild to drive the build. Custom commands
appear in MSBuild files inside CustomBuild elements, which appear inside
ItemGroup elements. The Outputs and AdditionalInputs elements of each
CustomBuild element are evaluated according to timestamps on disk.
MSBuild does not use inputs/outputs to order CustomBuild steps within a
single ItemGroup or across multiple ItemGroup elements. Instead we must
put only unrelated CustomBuild elements in a single ItemGroup and order
the item groups from top to bottom using a topological order of the
custom command dependency graph.
This fixes CustomCommand and ExternalProject test failures, so we remove
the expectation of these failures.
In each target we trace dependencies among custom commands to pull in
all source files and build rules necessary to complete the target. This
commit teaches cmTarget to save the inter-source dependencies found
during its analysis. Later this can be used by generators that need to
topologically order custom command rules.
Until now the VS 10 generator did no Windows command-line escaping and
just did XML escapes. This commit teaches the generator to use the same
command-line escape addition code used by other generators. The script
construction method cmLocalVisualStudioGenerator::ConstructScript need
not do XML escapes. Each VS generator version adds the XML escapes
necessary for that version.
It seems that
while(i=file.get(), file)
iterates one character too much on HP-UX, let's see whether
while(file.get(c))
works, at least this is given as example on http://h30097.www3.hp.com/cplus/ifstream_3c__std.htm
Alex
-add all global targets from CMAKE_BINARY_DIR to the menu, but not from the subdirs
-add all utility targets to the menu, except the Nightly/Experimental/Continuous-"sub"targets as e.
Alex
In cmTarget we trace the dependencies of source files in the target to
bring in all custom commands needed to generate them. We clean up the
implementation to use simpler logic and better method names. The new
approach is based on the observation that a source file is actually an
input (dependency) of the rule that it runs (compiler or custom) even in
the case that it is generated (another .rule file has the rule to
generate it).
This teaches cmTarget to use a set of cmSourceFile pointers to guarantee
unique insertion of source files in a target. The order of insertion is
still preserved in the SourceFiles vector.
When CMake is invoked by the VS IDE re-run rule we compute whether or
not CMake really needs to re-run based on some timestamp helper files.
Previously we assumed that if the main generate.stamp file exists then
VS has correctly detected that the file is out of date. However, this
assumption is too aggressive and re-runs CMake unnecessarily sometimes.
This commit removes the assumption and always checks timestamps itself.
The change breaks the explicit user re-run request (R-click -> Compile)
but only in cases when the build system is already up to date.
The VS generators use a ZERO_CHECK target on which all other targets
depend to check whether CMake needs to re-run. This commit simplifies
the addition of a dependency on the target to all other targets.
We also move addition of dependencies to the beginning of the Generate
step. This allows the dependency on ZERO_CHECK to be included in the
global inter-target dependency analysis.
Brad King
Alexander Neundorf
Zach Mullen
KWSys Robot
David Cole
Bill Hoffman
Clinton Stimpson
Ken Martin