During a try_compile cmGlobalGenerator::EnableLanguage uses results from
the outer project. Reject attempts to enable languages in the test
project that are not "ready" in the outer project. Mark a language as
"ready" when all its information has been loaded and we are ready to
generate build rules.
This also avoids infinite recursion introduced by commit 295b5b60 (Honor
CMAKE_USER_MAKE_RULES_OVERRIDE in try_compile, 2010-06-29) for projects
that set CMAKE_USER_MAKE_RULES_OVERRIDE to a file that uses try_compile.
The file is loaded along with the information for a given langauge so
the language is not yet "ready".
Remove a boolean parameter of cmGlobalGenerator::CreateGlobalTarget that
is never set to true anymore. Remove global target "consolidation" loop
because no global targets exist before it runs anymore.
This work was started from a patch by Thomas Schiffer.
Thanks, Thomas!
See the newly added documentation of the FOLDER target
property for details.
Also added global properties, USE_FOLDERS and
PREDEFINED_TARGETS_FOLDER. See new docs here, too.
By default, the FOLDER target property is used to organize
targets into folders in IDEs that have support for such
organization.
This commit adds "solution folder" support to the Visual
Studio generators. Currently works with versions 7 through
10.
Also, use the new FOLDER property in the ExternalProject
test and in the CMake project itself.
a99f620 Fix unused parameter warning in VS 7.1 generator
79a88c3 Refactor VS <= 7.1 utility-depends workaround
325bdb2 Factor out duplicate VS target dependency code
6bea843 Factor out global generator ComputeTargetDepends method
We store custom command rule hashes in CMakeFiles/CMakeRuleHashes.txt
persistently across CMake runs. When the rule hash changes we delete
the custom command output file and write a new hash into the persistence
file.
This functionality was first added by the commit 'Introduce "rule
hashes" to help rebuild files when rules change.' (2008-06-02).
However, the implementation in cmGlobalGenerator::CheckRuleHashes kept
the file open for read when attempting to rewrite a new file. On
Windows filesystems this prevented the new version of the file from
being written! This caused the first set of rule hashes to be used
forever within a build tree, meaning that all custom commands whose
rules changed would be rebuilt every time CMake regenerated the build
tree.
In this commit we address the problem by splitting the read and write
operations into separate methods. This ensures that the input stream is
closed before the output stream opens the file.
In cmGlobalGenerator::GetTargetSets we collect targets from all local
generators in a tree or subtree corresponding to a project() command.
Some targets, such as ALL_BUILD, are duplicated in each subdirectory
with a project() command. For such targets we should keep only the copy
for the top-most (root) local generator.
Previously this filtering was done in each VS IDE generator, but it is
easier to do it in one place when the targets are first encountered.
This also fixes bad ALL_BUILD dependencies generated for VS 7.0 because
the cmGlobalVisualStudio7Generator::WriteTargetDepends method was not
filtering out duplicates. Now we avoid duplicates from the start.
This commit cleans up the declaration, definition, and invocations of
the GetTargetSets method and related code. There is no change in
function except to make the method virtual.
This converts the CMake license to a pure 3-clause OSI-approved BSD
License. We drop the previous license clause requiring modified
versions to be plainly marked. We also update the CMake copyright to
cover the full development time range.
The try_compile command builds the cmTryCompileExec executable using the
cmTryCompileExec/fast target with Makefile generators in order to save
time since dependencies are not needed. However, in project mode the
command builds an entire source tree that may have dependencies.
Therefore we can use the /fast target approach only in one-source mode.
When building an entire source tree with try_compile instead of just a
single source file, it is possible that the CMakeLists.txt file in the
try-compiled project invokes try_compile. This commit fixes propagation
of language-initialization results from the outer-most project into any
number of try-compile levels.
Xcode does not seem to support direct requests for using the linker for
a particular language. It always infers the linker using the languages
in the source files. When no user source files compile with target's
linker language we add one to help Xcode pick the linker.
A typical use case is when a C executable links to a C++ archive. The
executable has no C++ source files but we need to use the C++ linker.
This generalizes the previous CMakeFiles/LabelFiles.txt created at the
top of the build tree to a CMakeFiles/TargetDirectories.txt file. It
lists the target support directories for all targets in the project.
Labels can still be loaded by looking for Labels.txt files in each
target directory.
The second argument of add_subdirectory must name a unique binary
directory or the build files will clobber each other. This enforces
uniqueness with an error message.
This creates a new LABELS property for targets and source files. We
write the labels of each target and its source files in target-specific
locations in the build tree for future use.
This simplifies computation of custom command rule hashes to hash
content exactly chosen as the custom commands are generated.
Unfortunately this will change the hashes of existing build trees from
earlier CMake versions, but this is not a big deal. The change is
necessary so that in the future we can make optional adjustments to
custom command lines at generate time without changing the hashes every
time the option is changed.
Previously the cmGlobalGenerator::GetDirectoryContent method would work
safely only during build system generation. These changes make it safe
to use during each configure step by flushing it at the beginning.
- The source-file signature of try_compile looks up the language
of the source file using the extension-to-language map so that
it knows what language to enable in the generated project.
- This map needs to be filled before loading a file specified by
CMAKE_USER_MAKE_RULES_OVERRIDE
CMAKE_USER_MAKE_RULES_OVERRIDE_<LANG>
so that the user file may call the try_compile() source-file
signature.
- It must still be re-filled after loading CMake<LANG>Information.cmake
in case the compiler- or platform-specific files added anything.
- See bug #7340.
Details:
==========
- New cpack_add_component, cpack_add_component_group, and
cpack_add_install_type "commands" defined as macros in the CPack
module.
- Documentation for all of the variables and commands in the CPack module.
- Added get_cmake_property(... COMPONENTS) to CMake to ask for the
names of all components. Used in the CPack module to automatically
build component-based installers. (Set CPACK_MONOLITHIC_INSTALL to
turn off component-based installation).
- A group can declare its PARENT_GROUP, to build an arbitrary
hierarchy of groups.
- New CPack command cpack_configure_downloads, which creates an
installer that downloads only the selected components on-the-fly.
Those components marked DOWNLOADED will be separate packages
downloaded on-the-fly (or, all packages can be marked as such with the
ALL option to cpack_configure_downloads). Individual components are
compressed with ZIP at installer-creation time and
downloaded/uncompressed by the installer as needed. This feature is
only available on Windows with NSIS at the moment.
- NSIS installers can install themselves and enable the "Change"
button in Add/Remove programs, allowing users to go back and install
or remove components. This can be disabled through
cpack_configure_downloads, because it's only really useful is most of
the application's functionality is in downloaded components.
- Bug fix: automatically install everything whose COMPONENT was not
specified (it's a hidden, required group)
- Bug fix: fixed removal of components when re-running the NSIS
installer and unchecking components
- Bug fix: NSIS installers now only install/remove the minimal
number of files when re-run to update the installation (or by clicking
"Change" in Add/Remove programs)
- The rule hash should use only commands specified by the user.
- No make output (echo and progress) rules should be included.
- No outputs or dependencies need be included. The native build tool
will take care of them.
- In CMake 2.4 custom commands would not rebuild when rules changed.
- In CMake 2.6.0 custom commands have a dependency on build.make
which causes them to rebuild when changed, but also when any
source is added or removed. This is too often.
- We cannot have a per-rule file because Windows filesystems
do not deal well with lots of small files.
- Instead we add a persistent CMakeFiles/CMakeRuleHashes.txt file
at the top of the build tree that is updated during each
CMake Generate step. It records a hash of the build rule for
each file to be built. When the hash changes the file is
removed so that it will be rebuilt.
- Previously this was done implicitly by the check for a target
link language which checked all source full paths.
- The recent change to support computing a link language without
finding all the source files skipped the implicit check.
- This change adds an explicit check to find all source files.
- Cycles may be formed among static libraries
- Native build system should not have cycles in target deps
- Create cmComputeTargetDepends to analyze dependencies
- Identify conneced components and use them to fix deps
- Diagnose cycles containing non-STATIC targets
- Add debug mode property GLOBAL_DEPENDS_DEBUG_MODE
- Use results in cmGlobalGenerator as target direct depends
- Created cmExportFileGenerator hierarchy to implement export file generation
- Installed exports use per-config import files loaded by a central one.
- Include soname of shared libraries in import information
- Renamed PREFIX to NAMESPACE in INSTALL(EXPORT) and EXPORT() commands
- Move addition of CMAKE_INSTALL_PREFIX to destinations to install generators
- Import files compute the installation prefix relative to their location when loaded
- Add mapping of importer configurations to importee configurations
- Rename IMPORT targets to IMPORTED targets to distinguish from windows import libraries
- Scope IMPORTED targets within directories to isolate them
- Place all properties created by import files in the IMPORTED namespace
- Document INSTALL(EXPORT) and EXPORT() commands.
- Document IMPORTED signature of add_executable and add_library
- Enable finding of imported targets in cmComputeLinkDepends
- This is purely an implementation improvement. No interface has changed.
- Create cmComputeLinkInformation class
- Move and re-implement logic from:
cmLocalGenerator::ComputeLinkInformation
cmOrderLinkDirectories
- Link libraries to targets with their full path (if it is known)
- Dirs specified with link_directories command still added with -L
- Make link type specific to library names without paths
(name libfoo.a without path becomes -Wl,-Bstatic -lfoo)
- Make directory ordering specific to a runtime path computation feature
(look for conflicting SONAMEs instead of library names)
- Implement proper rpath support on HP-UX and AIX.
Johan Björk
Brad King
Alex Neundorf
David Cole
Bill Hoffman