e8fdd5f1 QtAutogen: Workaround rcc CRCRLF newlines on Windows (#15459)
15f1a6b4 Tests/QtAutogen: Avoid touching files in the source tree
3f7c7c65 Tests/QtAutogen: Help Qt5Autogen test find Qt5 on Windows
26b5cc5e Tests/QtAutogen: Enable per-config source tests when possible
45566408 Tests/QtAutogen: Require CMake 3.1 to set policies everywhere
The 'rcc --list' operation may print newlines of the form CRCRLF,
so strip any trailing CR characters found on each line.
Update the Tests/QtAutogen test to use a resource named in a
subdirectory. This causes 'rcc --list' to display a blank line
and tests that it is correctly filtered out.
The rcc outputs are byproducts of the cmake_autogen rule, not outputs.
We still must run cmake_autogen on every run even if the rcc outputs
exist. Ninja requires explicit byproduct specification, which is now
possible in CMake since commit v3.2.0-rc1~340^2~2 (Add an option for
explicit BYPRODUCTS of custom commands, 2014-11-13). Revise the logic
introduced by commit v3.2.0-rc1~480^2 (QtAutogen: Regenerate qrc files
if their input changes, 2014-09-17) to specify byproducts explicitly.
55a73e6b Use the cmJoin algorithm where possible.
8dc8d756 cmStandardIncludes: Add a join algorithm for string containers.
b5813cee cmInstallCommand: Remove unused variable.
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.
Get dependencies from the output of ``rcc --list`` if using
Qt 5. Otherwise process the file in the same way as the
qt4_add_resources macro.
This does not work for RCC files which are generated.
The cmake_autogen build step is implemented as a PRE_BUILD step
of the target currently if possible, rather than a standalone
custom target. This is to keep the number of (synthesized)
custom targets that appear in the UI low, but in some cases
it is necessary to fall back to a full custom target.
Fall back to a full custom target for the VS builds if autorcc
is used.
Disallow the use of config-specific source files with
the Visual Studio and Xcode generators. They don't have
any way to represent the condition currently.
Use the same common-config API in cmQtAutoGenerators. While
it accepts config-specific files, it doesn't have to support
multiple configurations yet.
Loop over the configs in cmTargetTraceDependencies
and cmGlobalGenerator::WriteSummary and consume all source
files.
Loop over the configs in cmComputeTargetDepends and compute the
object library dependencies for each config.
Don't store a mapping of the directory to the ui file. The directory
will be a unique key, allowing only one ui file to be specified.
Use the source file name instead as the mapping key.
The rcc tool generates a cpp file with a symbol called qInitResources
or called qInitResources_${name}, if the name is passed. The
qInitResources symbol clashes if multiple qrc files are used in
one target.
Always pass the name to ensure that the symbol is unique. This is also
the behavior of the qtx_add_resource macros.
Use the clang RemoveCStrCalls tool to automatically migrate the
code. This was only run on linux, so does not have any positive or
negative effect on other platforms.
Visual Studio is handled as a special case for autogen depends. However,
the special handling works only for target dependencies, not file
dependencies output by a custom command.
Use a PRE_BUILD step only if all depends are targets.
When given a non-NULL configuration the GetLocation returned the
location for the given configuration. When given a NULL configuration
the GetLocation method returned a location with the build-system
placeholder for the configuration name. Split the latter use case out
into a separate GetLocationForBuild method and update call sites
accordingly.
Casts from std::string -> cmStdString were high on the list of things
taking up time. Avoid such implicit casts across function calls by just
using std::string everywhere.
The comment that the symbol name is too long is no longer relevant since
modern debuggers alias the templates anyways and the size is a
non-issue since the underlying methods are generated since it's
inherited.
Stephen Kelly
Brad King
Justin Borodinsky
Nils Gladitz
Clinton Stimpson
Bill Hoffman
Ben Boeckel
Kevin Funk