2d738ce3 Help: Add notes for topic 'feature_record_msvc'
f73718c9 Features: Enable writing of MSVC compiler feature header.
64c30bdc Features: Record for MSVC C++ 2015 and MSVC C 2010-2015.
225c0ef8 Features: Record for MSVC 2010-2013.
a15675ef Features: Quote all compiler names when comparing with COMPILER_ID
07d1f6fc Features: Properly evaluate if the compiler supports cxx_final.
6296192d Features: Add a comment explaining part of test.
c13656e7 Features: Test nullptr as a side-effect activation of static_assert.
3e34e833 Features: Test feature propagation with more-common features.
b3e86f4e Features: Test an expectation of whether OVERRIDE_CONTROL is expected
Notes:
VS2015 and above are the only MSVC versions to support cxx_final, so remove
usages from the tests, and instead only test for cxx_override.
VS2012 and above to conform to cxx_decltype_incomplete_return_types
proposal, but without support for auto return types the dcl.type.simple
example in the proposal doesn't compile.
VS2013 and above to conform to the updated cxx_contextual_conversions proposal,
but VS2010 and above pass the test.
Compilers such as MSVC have no explicit flags to enable C++11 mode,
it just is always on. So only run the link tests with compilers that require
a flag to specify the language version.
Previously we expanded HAVE_FINAL to determine what the copied_file number
would be, but when we don't have cxx_final than HAVE_FINAL is not defined.
What we really want is to use expected_result.
For complex*, CustomCommand and OutDir tests, non-ascii paths
are avoided in test code by using relative paths, and setting
the working when running the test. This also avoids the
need to internationalize the test code.
For RunCMake.GeneratorExpression, use a UTF-8 encoding in
file(STRINGS) to retrieve the compiled absolute path correctly.
Because not all compilers under test support the existing 'activation
features', add another test to ensure that compilers which support
both static_assert and nullptr behave as expected in this test.
The purpose of the feature listing in these tests is to make other
features from the same feature set (eg "C++11 features") available.
The compilers under test until now have supported these 'activation
features', but MSVC does not. Use the cxx_static_assert feature
instead to activate the feature set.
The tests below test the presence of both cxx_final and cxx_override,
only one of which is supported by MSVC. The test is in part intended
to verify that the COMPILE_FEATURES genex supports multiple arguments
and allows users to define names for groups of features (Clang already
calls cxx_final and cxx_override 'override control' as a group). Keep
the test, and allow the expectation to be set as appropriate.
Expect tests to specify stderr content if it is present.
Fix the CMP0019 test, which has only been testing the WARN status
until now. Specify in the CommandLine and FPHSA tests that content
is at least one character.
Set policies in the Language and CheckModules tests, which have empty
test output, modulo unrelated policies on some platforms.
07fc7b75 Tests: Test using objects from a language enabled in a subdirectory (#15325)
fdbfcfdf Ninja: Generate rules only for languages compiled in a target (#15325)
bb83cdaa Help: Add notes for topic 'AppleClang-5.1-features'
bd6b42c1 Features: Record for AppleClang 5.1
b341799e Tests: Fix RunCMake.CompileFeatures test NonValidTarget2 case
Add a test case that enables CXX in the top level and C in a subdirectory.
Create an executable in the top level that uses C objects compiled in the
subdirectory. Strictly speaking this is not defined behavior for all
language combinations, but happens to work in this case. Test this
behavior since projects might try to use it.
Mark the generated source file with the GENERATED property explicitly
since it is not marked automatically as the output of any custom
command. Mark both the 0 and 1 variants so it works no matter the
outcome of the generator expression.
b189c599 Tests: Run CFBundleTest only with valid configuration
3a605693 Xcode: Call IsCFBundleOnApple to decide if bundle is being built
207b7af0 cmTarget: Use GetCFBundleDirectory within GetFullNameInternal
The CTestTestMemcheck test cases all try to check the ctest output with
a regular expression. They fail intermittently due to ordering of the
portions of the output that come from stdout and stderr being mixed.
Convert all the test cases to use the RunCMake infrastructure to match
stdout and stderr separately.
29533380 Tests: Allow RunCMake expected result code to be a regex
a85ee8b8 Tests: Simplify RunCMake test extra argument passing
da7155f5 Tests: Allow RunCMake tests to pass generator expressions
Also add a 'CMAKE_ANDROID_API_MIN' variable to set the property
default. Teach the VS generator to write the MIN API value into
Nsight Tegra project files.
When install(EXPORT) is given an absolute destination we cannot compute
the install prefix relative to the installed export file location.
Previously we disallowed installation of targets in such exports with a
relative destination, but did not enforce this for target property
values besides the location of the main target file. This could lead to
broken installations when the EXPORT is installed to an absolute path
but usage requirements are specified relative to the install prefix.
Since an EXPORT installed to an absolute destination cannot be relocated
we can just hard-code the value of CMAKE_INSTALL_PREFIX as the base for
relative paths. This will allow absolute install(EXPORT) destinations
to work with relative destinations for targets and usage requirements.
Extend the ExportImport test with a case covering this behavior.
We use cmGlobalGenerator::GetDirectoryContent to avoid repeating
directory listings. However, GetDirectoryContent loads content from
disk at most once. This breaks find_library calls that occur when disk
content has changed since preceding find_library calls.
Teach cmGlobalGenerator::GetDirectoryContent to save the directory
modification time when content is loaded and re-load content if it
changes.
Create a RunCMake.find_library test with a case covering this.
Extend the BuildDepends test with a case covering multiple custom
command outputs with the second one consumed by another rule. With the
old "multiple output pair" infrastructure used in the Makefile and Xcode
generators this did not work. Now that it is fixed, test the case
explicitly.
If this option is enabled, the test step is created with the
EXCLUDE_FROM_MAIN option, and if TEST_BEFORE_INSTALL is enabled, the
install step does not depend on the test step.
This means that the test step is never executed, unless the test target
is explicitly created by calling ExternalProject_Add_StepTarget, or by
passing it with the STEP_TARGETS option, or with the EP_STEP_TARGETS
directory property.
Copy CMAKE_EXE_LINKER_FLAGS into the test project generated by
try_compile, just like we already copy CMAKE_<LANG>_FLAGS.
Add CMake Policy CMP0056 to activate this behavior in a compatible way,
but do not warn by default when the policy is not set since it will
affect all try_compile calls.
Extend the RunCMake.try_compile test with a case covering this behavior
for each policy setting.
Provide options to fail without blocking or to block up to a timeout.
Provide options to specify the scope containing the lock so it can be
released automatically at the end of a function, file, or process.
Extend the RunCMake.file test with cases covering the file(LOCK) command
usage and error cases.
Add a VS_DEPLOYMENT_LOCATION source file property to specify where to
put files that are part of the package. For example:
set_property(SOURCE ${ASSET_FILES} PROPERTY VS_DEPLOYMENT_LOCATION "assets")
Without this, sources marked with VS_DEPLOYMENT_CONTENT cannot be
located properly.
Create properties VS_SHADER_ENTRYPOINT and VS_SHADER_MODEL. Without
these many .hlsl source files may not be possible to use. Extend the
VSWinStorePhone test project to cover them.
8a75c7ef Help: Document the export limitation of INTERFACE_SOURCES.
e1348056 Export: Disallow export of targets with INTERFACE_SOURCES
bb5905bb cmTarget: Don't allow relative paths in INTERFACE_SOURCES
This can be allowed in the next release, but it needs to have some
features present and tested such as
* Ensuring that relative paths do not appear in the generated property.
* Ensuring that paths to the source or build directories do not appear.
* Generating a check in the file for CMake 3.1 or later so that the
resulting property will be consumed.
* Ensuring that any referenced targets are part of an export set and
generating a check for them.
* INSTALL_INTERFACE and BUILD_INTERFACE content.
All of these checks are already done for INTERFACE_INCLUDE_DIRECTORIES,
but it is too late to add them for INTERFACE_SOURCES for CMake 3.1.
As the checks introduce some new error conditions, it is better to
disallow exporting fully for this case and introduce proper error
conditions later instead of policies.
Follow the pattern of checks that are made for INTERFACE_INCLUDE_DIRECTORIES.
Existence is already checked by cmSourceFile::GetFullPath. Add a check
to disallow relative paths in source directories. Otherwise code such as
target_sources(lib1 INTERFACE foo.cpp)
would fail if consumed by a target in a different directory.
Unlike the INTERFACE_INCLUDE_DIRECTORIES behavior, we don't care whether
the entry comes from an IMPORTED target or not. In the include directories
case, the directory for a non-imported target might not exist yet but
might be created. In the sources case, a file which does not yet
exist in the filesystem must be explicitly marked with the GENERATED
property.
Adjust existing tests and add a new test for the error.
Extract a new method to encapsulate the requirements of evaluating
dependent-expressions, namely, propagation of the
EvaluateForBuildsystem setting, which is missing from the
getLinkedTargetsContent implementation.
Commit v3.1.0-rc1~688^2 (Genex: Only evaluate TARGET_OBJECTS to determine
target sources., 2014-03-20) introduced an error case for use of
TARGET_OBJECTS outside of the context of generating the buildsystem,
as the path to object files may be dependent on buildsystem
variables (See bug #15226).
Commit v3.1.0-rc1~314^2 (Allow INTERFACE_SOURCES to specify
$<TARGET_OBJECTS> (#14970), 2014-07-09) made it possible to
propagate such content to dependent targets.
While that commit propagated the EvaluateForBuildsystem setting
for the case of a TARGET_PROPERTY expression, as generated for
direct dependencies of a target in
cmTargetInternals::AddInterfaceEntries, it did not add propagation
for content from further transitive target dependencies, as determined
by getLinkedTargetsContent.
f327a9fd Merge branch 'default-lang-dialect' into step2
36bb100e Fix the test for running the CxxDialog unit test.
a3d0ae17 Features: Fix the default C dialect for Clang and GNU.
49e2b689 Features: Fix references to CXX compiler version in Clang-C.cmake.
7565ab2c Features: Test the CXX compiler only if it has features.
The __STDC_VERSION__ macro may be defined or not depending on the
implementation dialect of C. Test that it is defined before testing
its value.
The CXX tests do not need such a change because they define __cplusplus
in all dialects.
Extend the write_compiler_detection_header interface to allow
specifying a location for supplementary files, and getting the
list of resulting files as a variable.
The existing versions have been used since commit
v3.1.0-rc1~635^2~8 (cmTarget: Add CXX_STANDARD and CXX_EXTENSION
target properties., 2013-10-13), but further discussions since then
increased the initial minimum compiler versions this feature is
available for.
Clang 3.4 uses C99 by default, and Clang 3.6 uses C11 by default:
http://thread.gmane.org/gmane.comp.compilers.clang.devel/39379
GNU 4.9 uses C90 by default, and GNU 5.0 uses C11 by default:
https://gcc.gnu.org/gcc-5/changes.html
Test that the default compiler settings result in the expected dialect
macros being defined for both C and CXX. Remove the unused main.c
file from the CompileFeatures unit test.
Re-run if the input file changes or if the output file is removed.
This only works with the Makefile generators currently. The limitation
of the Ninja generator is tracked as issue #15256. The IDE
generators will need larger refactoring as they currently rely on
being able to determine the depends and output files at the start of
generate-time, which is too early for the file(GENERATE) case.
67bd514a Ninja: Refactor restat to be a string internally
ef42e57d Ninja: Use a TARGET_FILE variable to hold the link output file
592644c4 Tests/BuildDepends: Drop unneeded help for Ninja
2d75d7e5 Help: Add notes for topic 'console-pool'
f42d86f0 Ninja: Implement USES_TERMINAL using the console pool if available
f281ae01 Ninja: Remove unused declaration
d5eae556 Ninja: factor out the test for console pool support
4d1fedf4 Give the interactive cache editor the USES_TERMINAL property
fe5d6e8c Add USES_TERMINAL option for custom commands
ad6ee426 Rename doing_verbatim to doing_nothing
The external project's build process may generate byproducts on which
other rules in the driving project's build later depend. Provide a way
for the driving project to specify what byproducts it expects to be made
available by the custom commands that drive the external project.
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.
Teach the add_custom_command and add_custom_target commands a new
USES_TERMINAL option. Use it to tell the generator to give the command
direct access to the terminal if possible.
string SUBSTRING command now ignores length if it points
past end of string and uses end of string instead.
String SUBSTRING tests now cover more corner cases.
3c497f11 Help: Add notes for topic 'ExternalProject_UPDATE_DISCONNECTED'
aba5cec6 ExternalProject: Add unit tests for UPDATE_DISCONNECTED
3f606fa7 ExternalProject: Add UPDATE_DISCONNECTED option
c0b749cf ExternalProject: Always add a command to a step
The CPackComponentsForAll-*, GeneratorExpression, and
TestsWorkingDirectory tests all build binaries that they later
need to run or package for the tested configuration. Tell the
'ctest --build-and-test' call to use the same configuration
for driving the build process.
The evaluation files must be known before cmTargetTraceDependencies
attempts to find them, but we must actually generate the files after
cmTargetTraceDependencies, as that can add to target SOURCES. The
limitation is that the generated output name must not depend on the
SOURCES of a target if the generated file is used by that target.
Mark the output files as GENERATED so that trace dependencies does
not expect them to already exist in the filesystem.
Move the invokation of ForceLinkerLanguage in the Generate logic
to after the generated file names are known. ForceLinkerLanguage
tries to determine the sources of a target (in order to determine
an already-known language) and otherwise fails to get information
about the generated file.
Test that the output of file(GENERATE) can be used as a target source
file and that accessing the target SOURCES in the name of the output
file is an error. Accessing the TARGET_OBJECTS would be a similar
error if it was legal to use that generator expression in this
context. That is not currently possible and is a different error
condition, so test the current error output as a reminder to change
the expected output if that becomes possible in the future. Test
that generated rule files resulting from cmTargetTraceDependencies
appear in the SOURCES generated in the output file.
Since commit v3.1.0-rc1~227^2~1 (De-duplicate shared library targets in
generated link lines, 2014-07-30) we de-duplicate shared library targets
on the link line. However, some toolchains will fail linking if an
executable is linking to a shared library that is not used directly and
a static library that depends on the shared one. The linker may not
keep the reference to the shared library the first time and then the
symbols needed by the static library may not be found.
Fix this by reversing the direction of the for loop that removes the
duplicate shared libraries, in order to ensure that the last occurrence
of the library is left instead of the first one.
Extend Tests/Dependency with a case covering this behavior. Create an
executable that links to a shared library and a static library but only
needs the shared library as a dependency of the static library.
Co-Author: Brad King <brad.king@kitware.com>
c02c747b Tests: Update expected CTestTestFailedSubmit output
a427ed0c curl: Skip sanity check that triggers Clang warning
17b24d55 curl: Disable warnings to avoid changing 3rd party code
4c3bd340 curl: Skip check for inet_pton on Windows
54cb23c6 curl: Restore installation of OpenSSL DLLs
c50f0327 curl: Restore CURL_CA_BUNDLE option
681693c9 curl: Restore CMake-specific zlib selection code
10d80b68 curl: Restore CMake-specific test and install code
19593042 curl: Configure build to work within CMake
cf54aebb curl: Fix curl.h inclusion of curlbuild.h from CMake sources
c17e3207 curl: Use arch-aware CHECK_TYPE_SIZE results
1f7cb7e2 curl: Fix detection of headers with dependencies
b18c9044 curl: Drop inclusion of .rc file for static lib
860f0a2d curl: Select file APIs on Windows
5a3b55ed curl: Do not use 'dl' on HP-UX
59242702 curl: Simplify if() conditions on check result variables
...
b6b37e30 Makefile: Add assembly and preprocessed targets for Fortran
0842b084 Makefile: Refactor checks for lang-specific targets and export compile cmds
Brad King
Ben Boeckel
Robert Maynard
Stephen Kelly
Clinton Stimpson
Dmitry Polyanitsa
Kelly Thompson
Daniele E. Domenichelli
Ruslan Baratov
Gilles Khouzam
Cedric Perthuis
Gregor Jasny
Peter Collingbourne
Domen Vrankar