Refactoring in commit 66419bc046 (CTest: convert timeouts to
std::chrono::duration, 2017-11-20) accidentally changed the logic used
to compute the timeout for a test when it starts. It incorrectly limits
the maximum possible timeout to 2 minutes rather than 2 minutes less
than the total allowed test time remaining. Update the new logic to
restore the original behavior.
Avoid subtracting 2 minutes from our "infinite" timeout value to avoid
creating very large timeouts that are not "infinite" and may exceed
integer type ranges.
This commit continues the refactoring of CTest to adopt std::chrono.
After the last sets of changes that introduced std::chrono::steady_clock
and std::chrono::system_clock respectively, it makes sense to have all
the timeouts be stored as std::chrono::duration.
No functional change intended.
IWYU incorrectly classifies this internal STL type as not internal, and
suggests including `<type_traits>` for it. Work around the problem by
mapping the offending names to a file that we always include.
See include-what-you-use issue 434.
2ae880fa Genex: Enable COMPILE_LANGUAGE for COMPILE_OPTIONS with Visual Studio
2b7d59f3 Genex: Enable COMPILE_LANGUAGE for file(GENERATE) with Visual Studio
0f6f7c8a Genex: Fix COMPILE_LANGUAGE messages to allow file(GENERATE) with Xcode
c5a82d0f Tests: Decouple COMPILE_LANGUAGE in file(GENERATE) from COMPILE_OPTIONS
25773650 Tests: Remove unnecessary result files from RunCMake.File_Generate
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Jason Juang <jasjuang@gmail.com>
Merge-request: !1511
Some generators auto-generate targets. For example VS generators create
the ALL_BUILD target. Add the ability to mark targets as generator
provided and return that info through cmake-server codemodel.
Since commit v3.9.0-rc4~3^2~1 (VS: Fix target_compile_options for CUDA,
2017-06-21), the evaluation of `COMPILE_LANGUAGE` receives the proper
language. The set of compile flags used for a target's C and C++
sources is based on the linker language. By default this is always the
C++ flags if any C++ sources appear in the target, and otherwise the C
flags. Therefore we can define the `COMPILE_LANGUAGE` generator
expression in `COMPILE_OPTIONS` to match the selected language.
This is not exactly the same as for other generators, but is the best VS
can do. It is also sufficient for many use cases since the set of
allowed flags for C and C++ is almost the same in Visual Studio.
Furthermore, since the VS generator moves many of the flags to
declarative `.vcxproj` elements, it will automatically avoid passing
C++ flags for C sources.
Issue: #17435
40434631 Autogen: Use integers instead of strings for the Qt version
be11a852 Autogen: Use project relative paths in rcc custom command comment
ab9d5896 Autogen: Detect rcc feature once during configuration
2a85b5ac Autogen: Make cmQtAutoGeneratorInitializer an instantiable class
75819b86 Autogen: Add and use cmQtAutoGenerator base class
27ed3b35 Autogen: Rename cmQtAutoGenerators to cmQtAutoGeneratorMocUic
1cd285fe Autogen: Remove rcc code from cmQtAutoGenerators
a87f82e0 Autogen: Switch to use custom commands for RCC
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1494
If a partial message is flushed into the input pipe for CMake Server,
the parser will try and parse it as a full message because of some bad
loop checks. This was introduced accidentally in commit
v3.10.0-rc1~365^2~2 (server: Refactor to make the event loop owned by
server object, 2017-03-24).
We used to detect the `rcc` features before every `rcc` list invocation
wich resulted in `rcc` be called twice for every listing operation.
Now we detect the `rcc` list capabilities once during configuration and
pass it to the cmake_autorcc target in the info file.
Instead of processing all `rcc` invocation requests in the
_autogen target that calls `cmake -E cmake_autogen ...` once,
use a dedicated custom command that calls
`cmake -E cmake_autorcc ...` for each `.qrc` file.
This allows parallel `.qrc` file processing and reduces the
workload (and complexity) in the _autogen target.
If only `AUTORCC` is enabled, the _autogen target won't be created
at all since it is now used for `AUTOMOC` and `AUTOUIC` only.
For `.qrc` files that are GENERATED a custom target is used
instead of a custom command.
Closes#17161
Introduces the standalone RCC generator class `cmQtAutoGeneratorRcc`.
Every instance of `cmQtAutoGeneratorRcc` class handles the
`rcc` invocation for a single `.qrc` file.
The class will be used in the future to allow parallel `.qrc` file
processing by calling `cmake -E cmake_autorcc <INFO_FILE> <CONFIG>`.
When rejecting the `COMPILE_LANGUAGE` generator expression on include
directories and compile definitions with Xcode, add `file(GENERATE)` to
the allowed set in the message. It is allowed and already covered
by the `RunCMake.File_Generate` test `COMPILE_LANGUAGE-genex` case.
This reintroduces the change from commit v3.10.0-rc1~69^2 (Performance:
Improve efficiency of source file lookup in cmMakefile, 2017-08-17) with
some corrections. The original was rolled back by commit
v3.10.0-rc1~52^2~1 (Revert "Performance: ...", 2017-09-25) due to
incompatibilities found. The rollback was followed-up by addition of a
test for the offending case, and this revision passes the test.
After the refactor to make CTest use std::chrono::steady_clock for the
keeping of time for test duration, there are still references to
cmSystemTools::GetTime() left.
To further adopt std::chrono for time related activities, this commit
changes those remaining references to std::chrono::system_clock::now()
calls and alters the storage from either unsigned int or double to
std::chrono::system_clock::time_point.
For ease of conversion, a converter method is added to cmXMLWriter that
converts from a std::chrono::system_clock::time_point to the number of
seconds since the UN*X epoch as that is expected behaviour. This means
no more casts as required.
Functionally should be no difference as the system_clock is implemented
in the same terms.
Brad King