summaryrefslogtreecommitdiffstats
path: root/Tests/RunCMake/BuildDepends
Commit message (Collapse)AuthorAgeFilesLines
* GENERATOR_IS_MULTI_CONFIG: Use for multi-config checks in TestsCraig Scott2017-12-291-1/+1
|
* Tests: Fix RunCMake.BuildDepends on VS 2017 with v90 toolsetBrad King2017-08-251-1/+2
| | | | | The MSVC toolsets v100 and below forget to re-link when a manifest changes. Exclude this part of the test case for them.
* Tests: Use full output paths in file(GENERATE) callsBrad King2017-06-086-6/+6
| | | | | We don't define behavior for relative paths to the OUTPUT argument. Fix our tests to use full paths.
* Tests: Add case for IMPLICIT_DEPENDS in custom targetBrad King2017-04-265-0/+26
| | | | | | | | | | Use the `IMPLICIT_DEPENDS` option of `add_custom_command` and place the command in a custom target. Verify that `INCLUDE_DIRECTORIES` of that custom target are honored. This is a case that was not really designed to work but happens to work, is useful, and makes sense. Add a test case make sure it continues to work. Issue: #16830
* Tests: Split RunCMake.BuildDepends make-only conditionBrad King2017-04-261-3/+4
|
* Drop Visual Studio 7 .NET 2003 generatorBrad King2017-04-191-1/+1
| | | | This generator has been deprecated since CMake 3.6. Remove it.
* Use string(APPEND) in TestsDaniel Pfeifer2016-07-271-4/+4
| | | | | | | Automate with: find Tests -type f -print0 | xargs -0 perl -i -0pe \ 's/set\(([a-zA-Z0-9_]+)(\s+)"\$\{\1\}([^"])/string(APPEND \1\2"\3/g'
* Revise C++ coding style using clang-formatKitware Robot2016-05-162-2/+8
| | | | | | | | | | | | | Run the `Utilities/Scripts/clang-format.bash` script to update all our C++ code to a new style defined by `.clang-format`. Use `clang-format` version 3.8. * If you reached this commit for a line in `git blame`, re-run the blame operation starting at the parent of this commit to see older history for the content. * See the parent commit for instructions to rebase a change across this style transition commit.
* Tests: Fix RunCMake.BuildDepends filesystem delay for Watcom WMakeBrad King2016-04-291-1/+2
| | | | | Our 1.125s delay does not seem to be long enough to be reliable with the Watcom `wmake` tool. Use a longer delay for Watcom.
* Merge topic 'test-RunCMake.BuildDepends-filesystem-workaround'Brad King2016-04-111-0/+1
|\ | | | | | | | | f5e79004 Tests: Work around filesystem timestamp bugs in RunCMake.BuildDepends
| * Tests: Work around filesystem timestamp bugs in RunCMake.BuildDependsBrad King2016-04-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | The Custom-Symbolic-and-Byproduct case fails strangely on some filesystems used by our nightly testing. Somehow on the first build the `use-byproduct` output ends up with a timestamp older than `gen-byproduct-stamp` even though the build log clearly shows them build in the correct order (and must according to build system dependencies). Work around this problem by adding an extra delay before building `use-byproduct`. Tested-by: Gerhard Grimm <gerhard.grimm@detec.com>
* | Merge topic 'ninja-restat-custom-command-byproducts'Brad King2016-04-082-0/+29
|\ \ | |/ | | | | | | | | add7abc8 Ninja: Restat custom command byproducts even with a SYMBOLIC output (#16049) ff805113 Ninja: Fix detection of custom command symbolic outputs
| * Ninja: Restat custom command byproducts even with a SYMBOLIC output (#16049)Brad King2016-04-052-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The change in commit v3.5.0-rc1~198^2 (Ninja: Always re-run custom commands that have symbolic dependencies, 2015-11-19) broke the byproducts feature added by commit v3.2.0-rc1~340^2~2 (Add an option for explicit BYPRODUCTS of custom commands, 2014-11-13) when SYMBOLIC outputs also appear. This case occurs with AUTORCC-generated custom targets because the output is SYMBOLIC (to always run) and the generated file is a byproduct (for restat so dependents do not run unnecessarily). The two use cases conflict because Ninja does not support per-output restat. Favor restat whenever byproducts are present because it is required for byproducts to work correctly. In use cases where we want an always-run chain we simply will not be able to also use byproducts.
* | Tests: Add test for CMAKE_DEPENDS_IN_PROJECT_ONLY variableBrad King2016-03-235-0/+29
| |
* | Merge topic 'remove-vs6-generator'Brad King2016-03-101-1/+1
|\ \ | | | | | | | | | | | | | | | b42866a3 Drop Visual Studio 6 generator cd9ba3ec cmLocalVisualStudio7Generator: Fix name of helper function
| * | Drop Visual Studio 6 generatorBrad King2016-03-091-1/+1
| |/ | | | | | | | | | | This generator has been deprecated since CMake 3.3. Remove it. Update documentation, modules, and tests to drop content specific to this generator.
* | Xcode: ReRunCMake even if files disappeared (#15992)Gregor Jasny2016-03-091-0/+39
|/
* Ninja: Always re-run custom commands that have symbolic dependenciesBrad King2015-11-192-0/+26
| | | | | | | | | | | | If a custom command has a SYMBOLIC output (that is never actually created) then do not mark the custom command build statement as 'restat'. Otherwise other custom commands that depend on the symbolic output may not always re-run because after running the first custom command Ninja 'restat' will detect that the output timestamp did not change and skip its dependents. This was observed with the ExternalProject BUILD_ALWAYS option where Ninja would not re-run the 'install' step each time 'build' re-runs.
* Tests: Fix RunCMake.BuildDepends filesystem delay for Borland MakefilesBrad King2015-09-251-1/+7
| | | | | Our 1.125s delay does not seem to be long enough to be reliable with the Borland "make" tool. Use a longer delay for Borland.
* Add support for *.manifest source files with MSVC toolsBrad King2015-09-176-0/+46
| | | | | | | | Classify .manifest sources separately, add dependencies on them, and pass them to the MS manifest tool to merge with linker-generated manifest files. Inspired-by: Gilles Khouzam <gillesk@microsoft.com>
* Tests: Add RunCMake.BuildDepends testBrad King2015-09-176-0/+78
This will allow more granular checks than the main BuildDepends test. Start with a simple single-source C program.