| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
The -T parameter to CMake may now be specified through cmake-gui via a
new text field in the first-time configure wizard (below the generator
chooser).
The generator factories specify whether or not they support toolsets.
This information is propagated to the Qt code and used to determine if
the selected generator should also display the optional Toolset widgets.
|
|
|
|
|
|
|
| |
The configure-time and generate-time types should be completely
independent.
Add ownership of cmGeneratorTarget instances to the cmLocalGenerator.
|
|
|
|
| |
Find the target by looping when needed.
|
| |
|
| |
|
| |
|
|
|
|
| |
Not a map from cmTarget to cmGeneratorTarget.
|
|
|
|
| |
Don't store on the global generator as a side effect. Update clients to adapt.
|
|
|
|
|
|
|
| |
Mostly automated:
values=( "EXECUTABLE" "STATIC_LIBRARY" "SHARED_LIBRARY" "MODULE_LIBRARY" "OBJECT_LIBRARY" "UTILITY" "GLOBAL_TARGET" "INTERFACE_LIBRARY" "UNKNOWN_LIBRARY" "TargetType")
for i in "${values[@]}"; do git grep -l cmTarget::$i | xargs sed -i "s|cmTarget::$i|cmState::$i|g"; done
|
|
|
|
| |
Relieve cmMakefile of this responsibility.
|
|
|
|
| |
Reduce reasons for cmLocalGenerator to have a cmMakefile.
|
| |
|
|
|
|
|
| |
This method is a refactoring artifact. It will be removed in a
follow-up.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Refactor cmGlobalVisualStudioGenerator::TargetCompare to store the name of
the target that should come first instead of hard-coding "ALL_BUILD".
Update client sites to specify "ALL_BUILD" when ordering for .sln files
and an empty string otherwise (in cases when "ALL_BUILD" should not be
encountered anyway).
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| | |
Port callers away from it.
|
|/
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
It is required anyway, so this makes it explicit.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
This is much simpler than finding a way to lookup "CMAKE_COMMAND"
everywhere.
|
|
|
|
| |
Base class implementations for these are identical.
|
| |
|
| |
|
|
|
|
| |
Port generator factory methods to pass it.
|
|
|
|
|
|
|
| |
Pass the parent though cmGlobalGenerator::CreateLocalGenerator.
This will make it easy to initialize state scopes independent of
cmMakefile.
|
|
|
|
| |
Match names used in CMake code.
|
|
|
|
|
|
|
|
|
| |
* 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Move the condition to a "NeedsDeploy" virtual method that can be
overridden by more recent VS generators.
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
Continue to call GetOrCreateSource where necessary to create
cmSourceFile objects which have the GENERATED attribute set.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
All callers passed 0 in, so just remove the branch.
|
| |
|
| |
|
| |
|