Commit Graph

115 Commits

Author SHA1 Message Date
Stephen Kelly faec4e611d cmComputeTargetDepends: Change API to use cmGeneratorTarget. 2015-07-01 19:46:19 +02:00
Brad King d6fe79f3ab Merge topic 'remove-CMAKE_USE_RELATIVE_PATHS'
6e570f85 cmLocalGenerator: Remove 'optional' parameter from Convert.
3d8c6cd9 cmLocalGenerator: Remove obsolete method.
e44e6bcc Port away from obsolete method.
1335992c Remove CMAKE_USE_RELATIVE_PATHS variable.
2015-06-04 09:13:33 -04:00
Stephen Kelly 6e570f857a cmLocalGenerator: Remove 'optional' parameter from Convert.
Port callers away from it.
2015-06-04 09:06:09 -04:00
Brad King c85367f408 VS: Compute project GUIDs deterministically
Compute deterministic GUIDs that are unique to the build tree by
hashing the path to the build tree with the GUID logical name.
Avoid storing them in the cache, but honor any found there.
This will allow project GUIDs to be reproduced in a fresh build
tree so long as its path is the same as the original, which may
be useful for incremental builds.
2015-06-04 08:40:08 -04:00
Stephen Kelly c7b79aa16a cmGlobalGenerator: Require a cmake instance in ctor.
It is required anyway, so this makes it explicit.
2015-05-27 09:18:31 -04:00
Brad King 2f4bb4e9b0 VS: Do not accumulate configurations globally (#15577)
Drop the VS >= 7 generator's global Configurations member and instead
lookup configurations using cmMakefile::GetConfigurations where needed.
This avoids accumulating all CMAKE_CONFIGURATION_TYPES values ever
encountered by a project() or enable_language() command and allows
the final value to be used in each directory.  We don't officially
support per-directory CMAKE_CONFIGURATION_TYPES values but we certainly
should not generate configurations not in the final value in the top
level directory.
2015-05-21 09:06:49 -04:00
Brad King 6fbd4cae0d Use cmSystemTools::GetCMakeCommand() to get path to cmake internally
This is much simpler than finding a way to lookup "CMAKE_COMMAND"
everywhere.
2015-05-20 11:20:42 -04:00
Stephen Kelly dad8b03fbe VS: Remove obsolete methods.
Base class implementations for these are identical.
2015-05-19 11:02:34 -04:00
Stephen Kelly e435f875ec VS: Move version information to global generator. 2015-05-19 11:02:33 -04:00
Stephen Kelly b5f093f096 VS: Simplify setting of flag table. 2015-05-19 11:02:33 -04:00
Stephen Kelly 34c9ee2ed7 cmLocalGenerator: Require a global generator in the constructor.
Port generator factory methods to pass it.
2015-05-14 20:36:27 +02:00
Stephen Kelly a48aebcb67 cmLocalGenerator: Require a parent in the constructor.
Pass the parent though cmGlobalGenerator::CreateLocalGenerator.

This will make it easy to initialize state scopes independent of
cmMakefile.
2015-04-28 07:50:52 +02:00
Stephen Kelly 54d6a9187f cmMakefile: Rename GetCurrent{Output,Binary}Directory.
Match names used in CMake code.
2015-04-21 00:12:52 +02:00
Brad King 1e3843373f cmake: Show in --help how to select VS target platform (#15422)
* Re-order VS generators from newest to oldest.

* Show how to specify a VS generator with a target platform

* Increase the option output indentation to avoid extra wrapping
  with longer generator names.
2015-04-07 16:47:53 -04:00
Brad King e15a7075b5 Add an option for explicit BYPRODUCTS of custom commands (#14963)
A common idiom in CMake-based build systems is to have custom commands
that generate files not listed explicitly as outputs so that these
files do not have to be newer than the inputs.  The file modification
times of such "byproducts" are updated only when their content changes.
Then other build rules can depend on the byproducts explicitly so that
their dependents rebuild when the content of the original byproducts
really does change.

This "undeclared byproduct" approach is necessary for Makefile, VS, and
Xcode build tools because if a byproduct were listed as an output of a
rule then the rule would always rerun when the input is newer than the
byproduct but the byproduct may never be updated.

Ninja solves this problem by offering a 'restat' feature to check
whether an output was really modified after running a rule and tracking
the fact that it is up to date separately from its timestamp.  However,
Ninja also stats all dependencies up front and will only restat files
that are listed as outputs of rules with the 'restat' option enabled.
Therefore an undeclared byproduct that does not exist at the start of
the build will be considered missing and the build will fail even if
other dependencies would cause the byproduct to be available before its
dependents build.

CMake works around this limitation by adding 'phony' build rules for
custom command dependencies in the build tree that do not have any
explicit specification of what produces them.  This is not optimal
because it prevents Ninja from reporting an error when an input to a
rule really is missing.  A better approach is to allow projects to
explicitly specify the byproducts of their custom commands so that no
phony rules are needed for them.  In order to work with the non-Ninja
generators, the byproducts must be known separately from the outputs.

Add a new "BYPRODUCTS" option to the add_custom_command and
add_custom_target commands to specify byproducts explicitly.  Teach the
Ninja generator to specify byproducts as outputs of the custom commands.
In the case of POST_BUILD, PRE_LINK, and PRE_BUILD events on targets
that link, the byproducts must be specified as outputs of the link rule
that runs the commands.  Activate 'restat' for such rules so that Ninja
knows it needs to check the byproducts, but not for link rules that have
no byproducts.
2014-11-14 16:16:00 -05:00
Brad King b97736a23d VS: Implement CMAKE_GENERATOR_PLATFORM for VS >= 8
For VS generator names that do not specify the platform name, read
CMAKE_GENERATOR_PLATFORM to get it.

Extend the RunCMake.GeneratorPlatform test with a case covering
use of the x64 platform when the test generator is a Visual Studio
generator whose name does not specify a platform.
2014-09-05 15:03:56 -04:00
Brad King a43f44000d VS: Move internal MasmEnabled member up to VS 7 generator
Move the member from cmGlobalVisualStudio10Generator to
cmGlobalVisualStudio7Generator to make it useful for earlier
versions of VS.  Set the member to true only starting with
cmGlobalVisualStudio8Generator since we will not implement
MASM support for versions less than VS 8.
2014-08-20 10:21:12 -04:00
Gilles Khouzam fe161dc30d VS: Refactor logic deciding to add "Deploy" to the .sln file
Move the condition to a "NeedsDeploy" virtual method that can be
overridden by more recent VS generators.
2014-07-31 10:46:00 -04:00
Brad King 7a526c35f6 VS: Delay getting platform name in local generator
Ask the global generator during generation instead of trying
to store it up front.  Later the global generator may not know
the platform name when it is creating the local generator.
2014-07-17 16:59:53 -04:00
Brad King 6e176e6d9e VS: Delay platform definitions until system name is known
Move the definition of CMAKE_VS_PLATFORM_NAME and other variables that
are not needed by CMakeDetermineSystem out of the AddPlatformDefinitions
method and into a SetSystemName method.  The latter may later use
CMAKE_SYSTEM_NAME to decide what platform-specific definitions to add.
2014-07-17 16:34:21 -04:00
Brad King eeb60102e8 VS: Refactor CMAKE_FORCE_*64 platform definitions
Remove the general infrastructure for these additional platform
definitions and hard-code the only two special cases that used
it.  They are only for historical reasons so no new such cases
should be added.
2014-07-17 16:17:35 -04:00
Ben Boeckel 325599caa2 cmGlobalGenerator: Store targets in hash maps 2014-05-07 15:48:32 -04:00
Stephen Kelly 26d494ba01 cmTarget: Use string API to add sources to cmTarget objects.
Continue to call GetOrCreateSource where necessary to create
cmSourceFile objects which have the GENERATED attribute set.
2014-03-31 23:18:43 +02:00
Ben Boeckel 7abf4e313d stringapi: Use strings for dependency information 2014-03-08 13:05:39 -05:00
Ben Boeckel 1a1b737c99 stringapi: Use strings for generator names 2014-03-08 13:05:38 -05:00
Ben Boeckel 270eb96df0 strings: Remove cmStdString references
Casts from std::string -> cmStdString were high on the list of things
taking up time. Avoid such implicit casts across function calls by just
using std::string everywhere.

The comment that the symbol name is too long is no longer relevant since
modern debuggers alias the templates anyways and the size is a
non-issue since the underlying methods are generated since it's
inherited.
2014-03-08 13:05:35 -05:00
Ben Boeckel 8d60da0cb5 cmTarget: Remove the project argument to FindTarget
All callers passed 0 in, so just remove the branch.
2014-03-08 13:05:34 -05:00
Ben Boeckel c3833c7da4 stringapi: Use strings for VS project names 2014-03-08 13:05:33 -05:00
Ben Boeckel fabf1fbabb stringapi: Use strings in target name 2014-03-08 13:05:31 -05:00
Stephen Kelly ef25ba8d06 Constify handling of target dependencies. 2013-12-11 15:30:11 +01:00
Stephen Kelly 0bfcb450e6 INTERFACE_LIBRARY: Avoid codepaths which set unneeded properties.
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.
2013-11-25 16:17:50 +01:00
Brad King 558c74d0ab VS: Switch to internal CMAKE_MAKE_PROGRAM lookup by generators
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.
2013-11-18 11:30:50 -05:00
Brad King 5f5c92b9a2 VS: Add internal APIs to find MSBuild, devenv/VCExpress, and msdev
Teach the VS generators to compute the locations of these tools directly
from registry entries.  Add internal APIs to get the locations on demand.
2013-11-18 08:26:24 -05:00
Brad King 0c39a757da Drop the 'Full' field from cmDocumentationEntry
We need only 'Brief' for usage documentation.  We no longer have builtin
'Full' documentation, which is now in Help/*/*.rst files.
2013-10-16 09:22:37 -04:00
Brad King f8241136b4 Merge topic 'INTERFACE_LIBRARY-target-type'
ce0c303 install: Teach EXPORT option to handle INTERFACE_LIBRARY targets
435c912 export: Add support for INTERFACE_LIBRARY targets
fe73226 Add the INTERFACE_LIBRARY target type.
2013-10-08 10:58:40 -04:00
Stephen Kelly fe732264e9 Add the INTERFACE_LIBRARY target type.
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.
2013-10-07 19:56:31 -04:00
Brad King e478f03469 VS: Fix CMAKE_SUPPRESS_REGENERATION bad ZERO_CHECK dependency (#14378)
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>
2013-08-28 08:57:12 -04:00
Patrick Gansterer b02f09d434 VS: Replace ArchitectureId with PlatformName
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().
2013-08-05 13:38:26 +02:00
Patrick Gansterer 4b15dc855d VS: Set CMAKE_VS_PLATFORM_NAME for VS7 and VS71 too
Move the code which sets CMAKE_VS_PLATFORM_NAME from
cmGlobalVisualStudio8Generator to cmGlobalVisualStudio7Generator.
2013-08-05 13:38:23 +02:00
Patrick Gansterer 3a1006e41f VS: Added "Deploy" at project configuration for WindowsCE targets 2012-11-27 08:31:20 -05:00
Patrick Gansterer 40c36c9f7b VS: Make DetermineCompilerId working with WinCE too
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.
2012-11-27 08:31:19 -05:00
Patrick Gansterer 038df9e49e VS: Allow setting the name of the target platform
Since the name for a target platform is independent of its cpu
architecture an additional option is required to set it correctly.
2012-11-27 08:31:18 -05:00
Patrick Gansterer 6fe4fcba78 VS: Add parser for WCE.VCPlatform.config to read WinCE platforms
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.
2012-11-27 08:31:17 -05:00
Patrick Gansterer 102521b6b3 VS: Change variable type of ArchitectureId from const char* to string 2012-11-26 09:33:26 -05:00
Patrick Gansterer d41d4d3d61 VS: Add CMAKE_VS_PLATFORM_NAME definition to cmMakefile
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.
2012-11-26 09:33:24 -05:00
Brad King d82200df26 Merge topic 'generator-factory'
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
2012-11-20 11:48:05 -05:00
Brad King 508504ab6f Merge topic 'per-config-EXCLUDE_FROM_DEFAULT_BUILD'
739f166 Serialize tests for EXCLUDE_FROM_DEFAULT_BUILD
e31d83b Define property EXCLUDE_FROM_DEFAULT_BUILD
d1f8828 Add property EXCLUDE_FROM_DEFAULT_BUILD_<CONFIG>
b777272 Add tests for EXCLUDE_FROM_DEFAULT_BUILD
2012-11-20 11:47:35 -05:00
Patrick Gansterer 75ebebc39c VS: Remove platform specific generator files
Move the whole logic into the base class and the factory.
2012-11-19 14:56:29 -05:00
Patrick Gansterer 5bdf01184b VS: Remove GetPlatformName from platform-specific generators
Use the existing ArchitectureId to generate the PlatformName
to reduce duplicated information in the classes.
2012-11-19 14:10:25 -05:00
Patrick Gansterer 5170a8800f Make cmGlobalGenerator::GetDocumentation() a static function
Making the function static allows us to call it directly,
without creating and removing an instance of the generator.
2012-11-19 12:54:50 -05:00