As an INTERFACE_LIBRARY has no direct link dependencies, we can
short-circuit in cmGeneratorExpressionEvaluator and
in cmGlobalGenerator::CheckLocalGenerators.
As they do not generate any output directly, any generate- or install-
related code acn also be short-circuited. Many of the local generators
already do this.
Because only INTERFACE related properties make sense on INTERFACE_LIBRARY
targets, avoid setting other properties, for example via defaults.
Drop the "Modules/CMakeVS*FindMake.cmake" files. Override the
cmGlobalGenerator::FindMakeProgram method for VS generators to use their
internal APIs to locate the build tool. Set the CMAKE_MAKE_PROGRAM as a
normal variable for use by project code, but do not cache it. This will
allow CMake and CTest to select the proper tool at build time.
This target type only contains INTERFACE_* properties, so it can be
used as a structural node. The target-specific commands enforce
that they may only be used with the INTERFACE keyword when used
with INTERFACE_LIBRARY targets. The old-style target properties
matching LINK_INTERFACE_LIBRARIES_<CONFIG> are always ignored for
this target type.
The name of the INTERFACE_LIBRARY must match a validity generator
expression. The validity is similar to that of an ALIAS target,
but with the additional restriction that it may not contain
double colons. Double colons will carry the meaning of IMPORTED
or ALIAS targets in CMake 2.8.13.
An ALIAS target may be created for an INTERFACE library.
At this point it can not be exported and does not appear in the
buildsystem and project files are not created for them. That may
be added as a feature in a later commit.
The generators need some changes to handle the INTERFACE_LIBRARY
targets returned by cmComputeLinkInterface::GetItems. The Ninja
generator does not use that API, so it doesn't require changes
related to that.
When CMAKE_SUPPRESS_REGENERATION tells us not to create the ZERO_CHECK
target we should not add dependencies on it from other targets either.
Reviewed-by: Mateusz Loskot <mateusz@loskot.net>
Since we do not need the information about the target architecture
we can use the PlatformName only to specify the this information.
This also removes setting of the MSVC_*_ARCHITECTURE_ID variable
which is not required, because this variable gets set by the
compiler detection code in CMAKE_DETERMINE_COMPILER_ID_CHECK().
Add a dummy mainCRTStartup() function, since the linker searches for
it instead of main() and set the CMAKE_SYSTEM_* variables depending
on the MSVC_C_ARCHITECTURE_ID and CMAKE_VS_WINCE_VERSION variables.
Parse the WCE.VCPlatform.config file, which contains the installed
WindowsCE SDKs in XML format, and add possibility to generate
Visual Studio generators for them.
When adding more platforms to the Visual Studio generators a simple
regular expressing can not handle all cases anymore. This new
define holds the name of the Visual Studio target platform.
75ebebc VS: Remove platform specific generator files
8b62080 VS: Remove EnableLanguage from platform-specific generators
5bdf011 VS: Remove GetPlatformName from platform-specific generators
8d42ab4 VS: Fix ArchitectureId of Visual Studio 10 IA64 generator
6f439b3 VS: Remove AddPlatformDefinitions from platform-specific generators
5170a88 Make cmGlobalGenerator::GetDocumentation() a static function
04ff866 Allow a GeneratorFactory handling of more than one generator
984ebc3 Search generator in cmake::ExtraGenerators before in cmake::Generators
30a6950 Add cmGlobalGeneratorFactory::GetGenerators()
e8f8414 Introduce the abstract class cmGlobalGeneratorFactory
Teach Windows-cl.cmake to use CMAKE_(C|CXX)_COMPILER_VERSION to set the
"MSVC##" and MSVC_VERSION variables. It no longer needs the IDE generator
to dictate the version or to detect the version by running the
command-line tool for NMake and Ninja generators. Drop configuration of
CMakeCPlatform.cmake and CMakeCXXPlatform.cmake from Windows-cl.cmake.in
because all the results it saved are now cheap to compute every time.
Teach cmMakefile::AddCustomCommandToOutput to return the cmSourceFile
instance to which the custom command is attached. Use the return value
instead of separately adding a .rule extension and searching for the
source. Mark CMake-generated .rule files explicitly with a property
instead of trusting the file extension.
Move the Version member to the top cmLocalVisualStudioGenerator class
and set it consistently for instances created by all the global
generator versions. Use an enumeration type with values scaled by a
factor of 10 so we can handle VS 7.1 without out-of-order numbers.
VS 7.1 support for SuppressStartupBanner was broken by commit 25116a3c
(Fix CMAKE_VERBOSE_MAKEFILE for VS10 vcxproj files, 2011-10-11) because
it assumed comparison of VS version numbers works. Now it does.
Commit 1a0c166 (Store direct dependencies in solutions for VS >= 8,
2010-08-20) disabled use of VS-specific global dependency analysis.
Avoid perfoming the analysis at all when it is not needed. This also
prevents creation of bogus and unused '_UTILITY' targets since they are
not needed for dependencies.
Since commit bc43b0f2 (Do not link library dependencies in VS solutions,
2009-10-20) CMake disables for VS >= 8 linking of a target to libraries
that happen to be listed as solution-level dependencies. Therefore we
can list the direct dependencies of each target in the solution file and
let VS handle transitive dependencies automatically.
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.
In VS 8 and greater this commit implements
add_dependencies(myexe mylib) # depend without linking
by adding the
LinkLibraryDependencies="false"
option to project files. Previously the above code would cause myexe to
link to mylib in VS 8 and greater. This option prevents dependencies
specified only in the solution from being linked. We already specify
the real link library dependencies in the project files, and any project
depending on this to link would not have worked in Makefile generators.
We were already avoiding this problem in VS 7.1 and below by inserting
intermediate mylib_UTILITY targets. It was more important for those
versions because if a static library depended on another library the
librarian would copy the dependees into the depender! This is no longer
the case with VS 8 and above so we do not need that workaround.
See issue #9732.
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.
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 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.
- ZERO_CHECK should check all stamps in case
of parallel build (fixes complex test failure)
- ZERO_CHECK should not appear when
CMAKE_SUPPRESS_REGENERATION is on (fixes bug 6490)
- 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
"imported" executable target. This can then be used e.g. with
ADD_CUSTOM_COMMAND() to generate stuff. It adds a second container for
"imported" targets, and FindTarget() now takes an additional argument bool
useImportedTargets to specify whether you also want to search in the
imported targets or only in the "normal" targets.
Alex
Ben Boeckel
Stephen Kelly
Brad King
Patrick Gansterer
Petr Kmoch
Kitware Robot
David Cole
Leonid Yurchenko
Sebastian Herbst
Bill Hoffman
Ken Martin
Alexander Neundorf