Using XXX as name of the package is ambiguous, since it can be
interpreted as "ALLUPPERCASE" and also as "ExactCase (if the name
is already ALLUPPERCASE)".
After extensive discussion there is the conclusion that ExactCase
is intended, so using a CamelCased name makes that more obvious.
Alex
Modify add_jar to (partly) use cmake_parse_arguments, and to require
using the named argument list INCLUDE_JARS to specify jar files (or jar
targets) to use as dependencies when creating a jar. This preserves the
ability to have such, while restoring the historic behavior that jar
files listed as sources are ignored. (The code now explicitly ignores
them, however, rather than adding them to an unused local variable, so
that it is more clear that nothing is being done with them.)
In GNU.cmake, -isystem is not used if APPLE is set. However, Clang has
pretty much always supported -isystem, so we should always use it.
In the future, GNU.cmake should do a version check to see if -isystem is
supported.
27e6f6e TI compiler: add automatic detection of prefix and suffixes
b301586 rename TI_DSP toolchain to TI, since it works also for the ARM compiler
12b25df Determine C/CXX/Fortran compiler: fix indentation
7baa55a Determine C/CXX/Fortran compiler: minor restructuring
Use normal custom command dependencies by default. Use the PRE_LINK
approach only to work around what seems to be a bug in msbuild handling
of custom build rules that chain together.
Fix setting classpath when encountering a jar argument to add_jar to
actually set the variable that is used to specify the classpath to
javac, instead of just uselessly appending the jar to
CMAKE_JAVA_INCLUDE_PATH (which is never used again at the point where it
is modified). Also, list jars so specified as dependencies of compiling
the java sources for the jar target.
According to XL C/C++ V9.0 documentation the default for -qpic/-qnopic
is platform-dependent. It won't hurt to add the option on platforms
where it is the default, so always add it when we want position
independent code.
d90f49b CTest: Fail early without PROJECT_BINARY_DIR (#14005)
2e1c2bd build_command: Fail early without CMAKE_MAKE_PROGRAM (#14005)
4e5cb37 Refactor RunCMake.build_command test to allow more cases
The parent commit accidentally referenced QT_QMAKE_QMAKE_EXECUTABLE
which does not exist. Use QT_QMAKE_EXECUTABLE instead.
Reported-by: m.hergarden@euphoria-it.nl
Do not use PROJECT_BINARY_DIR before it is defined. If it is not
defined when needed, fail with an error message suggesting that the
project() command be invoked first.
The CMake language implicitly flattens lists so a ";" in a list element
must be escaped with a backslash. List expansion removes backslashes
escaping semicolons to leave raw semicolons in the values. Teach
ExternalData_Add_Test and ExternalData_Expand_Arguments to re-escape
semicolons found in list elements so the resulting argument lists work
as if constructed directly by the set() command.
For example:
ExternalData_Add_Test(Data NAME test1 COMMAND ... "a\\;b")
ExternalData_Expand_Arguments(Data args2 "c\\;d")
add_test(NAME test2 COMMAND ... ${args2})
should be equivalent to
set(args1 "a\\;b")
add_test(NAME test1 COMMAND ... ${args1})
set(args2 "c\\;d")
add_test(NAME test2 COMMAND ... ${args2})
which is equivalent to
add_test(NAME test1 COMMAND ... "a;b")
add_test(NAME test2 COMMAND ... "c;d")
Note that it is not possible to make ExternalData_Add_Test act exactly
like add_test when quoted arguments contain semicolons because the CMake
language flattens lists when constructing function ARGN values. This
re-escape approach at least allows test arguments to have semicolons.
While at it, teach ExternalData APIs to not transform "DATA{...;...}"
arguments because the contained semicolons are non-sensical.
Suggested-by: Jean-Christophe Fillion-Robin <jchris.fillionr@kitware.com>
Wihtout this, if qmake binary is from Qt5 the FindQt4 fails even though
the Qt4 version of qmake would be installed as qmake-qt4.
On Archlinux this is the case.
Reviewed-by: Clinton Stimpson <clinton@elemtech.com>
In addition to adding the cupti library, find_local_library_first has
been renamed to cuda_find_local_library_first with a backward
compatibility macro to find_local_library_first. Also added
cuda_find_local_library_first_with_path_ext to handle different paths.
This adds a new variable, CUDA_SEPARABLE_COMPILATION, and two new
functions, CUDA_COMPUTE_SEPARABLE_COMPILATION_OBJECT_FILE_NAME and
CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS.
When CUDA_SEPARABLE_COMPILATION is specified then CUDA runtime objects
will be compiled with the separable compilation flag. These object
files are collected in a target named variable that can be used in
CUDA_COMPUTE_SEPARABLE_COMPILATION_OBJECT_FILE_NAME and
CUDA_LINK_SEPARABLE_COMPILATION_OBJECTS.
