The nvcc device linker is designed so that each static library
with device symbols only needs to be listed once as it doesn't
care about link order. If you provide the same static library
multiple times it will error out. To make sure this occurs
we find the unique set of link items.
Prior to commit 7c4c13ffef (math: Reject unexpected expression input
explicitly, 2018-05-18) we ignored unexpected characters in an
expression that otherwise can be parsed. In order to preserve
compatibility with projects that accidentally used this, convert the
error to a warning.
CPack creates cpack_variables.wxi in the build directory. In the WiX
template it can be used by <?include "cpack_variables.wxi"?> because
the template is configured into main.wxs in the build directory.
Because the extra source files are in the source directory it was necessary to use
<?include "$(sys.CURRENTDIR)_CPack_Packages\win32\WIX\cpack_variables.wxi"?>.
This requires knowledge about the build directory structure and
is avoided by this change by adding the build directory to the IncludeSearchPaths.
-- Use the specified toolset located within GHS_TOOLSET_ROOT
-- Update how the latest toolset is determined; scan the location GHS_TOOLSET_ROOT and sort it
No longer use registry settings looking for installations
The registry values are assigned in installation order for Green Hills tools not version order
-- Update to use gbuild.exe from the proper toolset
-- Clarify that CMAKE_MAKE_PROGRAM should not be set by user.
-- Detect some toolset changes when regenerating project files
This could occur if GHS_TOOLSET_ROOT was changed by user after the initial project generation
This could occur if CMAKE_MAKE_PROGRAM was changed at the command line
-- Use placeholder values for CMAKE_<LANG>_COMPILER
The MULTI build system only uses gbuild to build a project
gbuild uses the project file to determine which set of compilers to use based on target platform and architecture
because compiler detection is skipped, placeholder values are used so that CMake does not complain
cmQtAutoGenInitializer::InitCustomTargets and
cmQtAutoGenInitializer::SetupCustomTargets
now return their success value which gets evaluated
and passed on by the caller (cmGlobalGenerator).
Checks for the existance of the moc/uic/rcc
binaries have been introduces in cmQtAutoGenInitializer.
Additionally they get called once with a "-h"
argument to determine if they're functional.
This way any binary-not-found problem is caught
during the configuration phase.
Use the more portable `isprint()` function to test characters rather
than using hard-coded hex values. The function is documented by the C++
standard to return non-zero for the exact range of hex values we
previously hard-coded, so this should not change behavior.
Previously we would warn when the local and cache version of a variable
exists, but this use case doesn't need a warning as it maintains backwards
compatibility.
3b2ea092ef Help: Add documentation for DEPLOYMENT_ADDITIONAL_FILES
b771b2c300 VS: extended OutputDeploymentDebuggerTool for AdditionalFiles
2f4075fa45 VS: moved EscapeForXML function higher up and made static
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2184
2a5f5c0e31 option: respect existing normal variable
12e6f83319 Option: Add a test that verifies interaction with normal variables
5bb3d40a28 cmOption: Remove VTK 4.0 workarounds
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2155
The `OutputDeploymentDebuggerTool` function now also retrieves a target
property that is used for setting the `AdditionalFiles` attribute of
`DeploymentTool`.
-- Update -A option to choose target architecture.
-- Update commentary about which variables are used to control toolset and target settings
-- Remove setting CMAKE_SYSTEM_PROCESSOR because the value is overwritten to be "" by subsequent CMAKE processing
When `*.cs` files are provided, do not generate a `<Link>` element in
the `.csproj` project if those files are descendants of
`CMAKE_CURRENT_BINARY_DIR`. This comparison happens for each file.
