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.
KWSys tries not to force anything on source files that include its
headers, but Borland warning 8027 leaves us no choice when we want to
have inline function definitions. This commit disables the warning for
the RegularExpression header and any file that includes it.
Until now CMake accidentally accepted add_subdirectory() and subdirs()
calls referring to directories that do not contain a CMakeLists.txt
file. We introduce CMake Policy CMP0014 to make this case an error.
This method tells the cmMakefile to read the input CMakeLists.txt file.
We factor out the call into a ReadInputFile method so it can be extended
without polluting the Configure method.
Much of the code in this method was dedicated to computing ObjectMaxPath
after configuring the directory. We move this last step into its own
ComputeObjectMaxPath method for better organization.
The cmLocalGenerator::Configure method sets its cmLocalGenerator
instance as the global generator's current local generator during
configuration. This commit refactors management of the current local
generator to use an automatic variable. This will allow early returns
from the method.
CMake Makefile generators silently ignore missing CMakeLists.txt files
and just treat the source directory as if it had an empty input file.
This will be addressed with a new CMake Policy, but for now we make the
VS generator consistent with the Makefile generator behavior. The VS
generator will need to handle the OLD behavior of the policy anyway.
The cmGlobalGenerator::AddTargetDepends method traces the dependencies
of targets recursively to collect the complete set of targets needed for
a given project (for VS .sln files). This commit teaches the method to
avoid tracing its dependencies more than once. Otherwise the code does
an all-paths walk needlessly.
Part of this test does "git pull" on a dirty work tree. We need to make
sure that 'branch.master.rebase' is false for the test repository.
Otherwise if it is true in the user configuration then pull will refuse
to rebase and the test will fail.
We teach the FindPackageTest to build a sample project that stores its
build tree in the user package registry using export(PACKAGE), and then
find it with find_package.
We define the export(PACKAGE) command mode to store the location of the
build tree in the user package registry. This will help find_package
locate the package in the build tree. It simplies user workflow for
manually building a series of dependent projects.
A common user workflow is to build a series of dependent projects in
order. Each project locates its dependencies with find_package. We
introduce a "user package registry" to help find_package locate packages
built in non-standard search locations.
The registry explicitly stores locations of build trees providing
instances of a given package. There is no defined order among the
locations specified. These locations should provide package
configuration files (<package>-config.cmake) and package version files
(<package>-config-version.cmake) so that find_package will recognize the
packages and test version numbers.
The commit "Split Intel compiler information files" moved some Linux
specific flags into the platform-independent Intel compiler info files.
This moves them back.
The verification program entry point (main) is defined in a C source
file, so the C compiler should be used to link when only Fortran and C
are involved. The C++ compiler should still be used when the CXX option
is enabled.
We test that LINK_INTERFACE_MULTIPLICITY propagates through export() and
install(EXPORT) into dependent projects. A simple cycle of two archives
that need to be scanned three times ensures that the importing project
uses the multiplicity correctly.
We create target property "LINK_INTERFACE_MULTIPLICITY" and a per-config
version "LINK_INTERFACE_MULTIPLICITY_<CONFIG>". It sets the number of
times a linker should scan through a mutually dependent group of static
libraries. The largest value of this property on any target in the
group is used. This will help projects link even for extreme cases of
cyclic inter-target dependencies.
Bill Hoffman
Clinton Stimpson
David Cole
Zach Mullen
Brad King
KWSys Robot
Ken Martin