Expect cxx_variadic_templates to implement N2555.
N2555 is essentially a bugfix and predates most compiler releases which
aimed to experimentally support variadic templates.
This can be used to set the compiler features required by particular
targets. An error is issued at CMake time if the compiler does not
support the required feature. If a language dialect flag is required
by the features used, that will be added automatically.
Base the target_compile_features command on cmTargetPropCommandBase. This
gives us 'free' handling of IMPORTED, ALIAS, INTERFACE, non-compilable
and missing targets.
Extend the interface of the target_compile_features command with
PUBLIC and INTERFACE keywords. Populate the INTERFACE_COMPILER_FEATURES
target property if they are set. Consume the INTERFACE_COMPILER_FEATURES
target property from linked dependent targets to determine the final
required compiler features and the compile flag, if needed.
Use the same pattern of origin-debugging which is used for other
build properties.
Record the availability of this feature for GNU 4.8 on (UNIX AND
NOT APPLE) only. In the future, availability can be recorded for
earlier GNU, for other platforms and for other compilers. Initially
the affected configurations are as restricted as possible to allow
for easy testing while extending the features vector in only one
dimension.
The error message when using the set_property API directly is not
very good, but follow up commits will provide origin debugging of
the property and a target_compile_features command which will
provide a configure-time backtrace when possible.
Use the contents of it to upgrade the CXX_STANDARD target property,
if appropriate. This will have the effect of adding the -std=c++11
compile flag or other language specification on GNU when that is
needed for the feature.
a4e6bf8e cmTarget: Make GetSourceFiles string overload private.
92e2fbe1 cmGeneratorTarget: Trace cmSourceFile objects instead of strings.
c5b26f3b cmTarget: Cache the cmSourceFiles in GetSourceFiles.
eb163f37 cmTarget: Extract a ProcessSourceItemCMP0049 method.
19b7c22d Ninja: Query custom commands once per target, not once per file.
This reverses the decision in commit d38423ec (cmTarget: Add a
method to obtain list of filenames for sources., 2014-03-17). The
cmSourceFile based API is preferred because that avoids creation of
many cmSourceFileLocation objects for matching strings, and the
result is cached by cmTarget.
Avoid calling GetSourceFiles with the same result container multiple
times when tracing target dependencies. The result from the previous
configuration is cached and used later otherwise.
Avoid calling AddSource for each src filename. That involves
checking each entry for uniqueness and creating a separate
generator expression for each one.
Instead, add a single entry for the list of sources. The source
files are passed through a uniqueness filter at generate-time, so
duplicates don't matter so much.
The compilation failed with this error message:
.../Source/cmCryptoHash.cxx: In method `string cmCryptoHash::HashString (const string &)':
.../Source/cmCryptoHash.cxx:41: non-lvalue in unary `&'
This was introduced in 77f60392d9 (stringapi:
Accept strings when MD5 hashing data).
6c190245 Remove extra semicolons from C++ code.
4bef02e7 cmTypeMacro: Add a class to eat the semicolon following the macro use.
ff710539 Remove default labels from fully covered switch statements.
9407174b target_sources: New command to add sources to target.
81ad69e0 Make the SOURCES target property writable.
6e636f2e cmTarget: Make the SOURCES origin tracable.
3676fb49 cmTarget: Allow transitive evaluation of SOURCES property.
e6971df6 cmTarget: Make the source files depend on the config.
df753df9 cmGeneratorTarget: Don't add computed sources to the target.
869328aa cmComputeTargetDepends: Use valid config to compute target depends.
5de63265 Genex: Only evaluate TARGET_OBJECTS to determine target sources.
aa0a3562 cmGeneratorTarget: Compute target objects on demand
042c1c83 cmTarget: Compute languages from object libraries on demand.
fdcefe3c cmGeneratorTarget: Compute consumed object libraries on demand.
c355d108 cmComputeTargetDepends: Track object library depends.
e5da9e51 cmTarget: Allow any generator expression in SOURCES property.
5702e106 cmTarget: Include TARGET_OBJECTS genex in target SOURCES property.
857d30b5 cmGlobalGenerator: Add interface to call ForceLinkerLanguages
28e1d2f8 cmStringCommand: Add GENEX_STRIP subcommand.
bf98cc25 Genex: Evaluate TARGET_OBJECTS as a normal expression.
8cd113ad cmTarget: Store strings instead of cmSourceFile* to represent SOURCES.
4959f341 cmSourceFileLocation: Collapse full path for directory comparisons.
fcc92878 cmSourceFileLocation: Remove unused Update method.
59e8740a cmTarget: Remove AddSourceFile method
26d494ba cmTarget: Use string API to add sources to cmTarget objects.
d38423ec cmTarget: Add a method to obtain list of filenames for sources.
...
13684e2b cmMakefile: Port PolicyOptionalWarningEnabled to string APIs
8018fcca Merge branch 'master' into revise-compiler-id-policies
a41c0a9d Do not warn by default when policy CMP0025 or CMP0047 is not set
d339653e Help: Revise and format policy CMP0025 and CMP0047 docs
e8633e66 VS: Fix /analyze:log flag mapping (#14858)
650199e7 VS: Support mapping flags with values following separately (#14858)
f2a3dd9d cmIDEOptions: Factor FlagMap update out to separate method
Extend the cmGeneratorExpressionDAGChecker with an interface
returning the name of the top target. Use that to determine
when there is a DAG violation, as required by the RunCMake.Languages
tests.
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.
When config-specifig generator expressions are supported, a target
may have SOURCES:
src1.cpp $<$<CONFIG:Debug>:src2.cpp> $<$<CONFIG:Release>:src3.cpp>
and computation in cmTargetTraceDependencies would add each of the
src2.cpp and src3.cpp sources back to the target without a
config-guard. That would make the sources be used later when
generating the buildsystem, regardless of the configuration.
Avoid calling AddSource on the target with the result of the
GetSourceFiles call.
If CMAKE_BUILD_TYPE is set, and user code contains:
target_link_libraries(myexe prefix_$<$<CONFIG:Debug>:debug>)
then the computation with an empty config was computing a target-level
dependency on a target or library called prefix_, and a dependency
on a target or library called prefix_debug (as expected).
The existing logic skips 'prefix_' because it is not a known target,
and defers to the link-dependencies logic to find the library. The
link-dependencies logic does not incorrectly handle the config as
cmComputeTargetDepends did, and so did not encounter 'prefix_'
during its computation. This likely had no effect on the generated
buildsystem.
The output of this expression may contain macros for IDEs to replace
such as $(Configuration), $(CURRENT_ARCH) etc. To avoid generating
content which is not usable in other contexts, report an error if
there is an attempt to use it in other contexts.
This commit may be reverted in the future if a solution to the
above difference is implemented.
Add a ComputeObjectMapping method to compute the object
names. It takes mapping to populate as an out-parameter so
that it can be extended in the future with parameters
relevant to generator expression evaluation.
Remove the supporting cmGeneratorTarget::AddObject method. It is
no longer needed as the container member is populated directly.
The ComputeObjectMapping method is called whenever objects are
requested from the cmGeneratorTarget. Because the Xcode generator
makes no such request, explicitly invoke the method from that
generator so that the logic of checking for bad sources in object
libraries is executed.
In a follow-up, the UseObjectLibraries usage may be replaced by a
true generator expression evaluator for TARGET_OBJECTS. That
will require generators to use cmGeneratorTarget::GetExternalObjects
which is not currently the case for Xcode and VS generators.
Remove use of UseObjectLibraries from Makefile and Ninja generators. It
is not needed now because those generators use GetExternalObjects
which already contains the objects from object libraries.
The VS10 generator calls both the UseObjectLibraries and the GetExternalObjects
methods. Ensure that duplicates are not created by skipping objects
from object libraries in handling of GetExternalObjects.
Similarly, fix VS6, VS7 and Xcode object handling by skipping
external objects from OBJECT_LIBRARY usage as appropriate.
The error message in the BadSourceExpression1 test is now reported
by the generator expression evaluator, so it has different text.
This method was added in a commit based on a release branch that
pre-dated the std::string API changes. Port the implementation to use
the string APIs instead of c_str().
These policies are triggered by the use of a particular compiler rather
than outdated CMake code in a project. Avoid warning in every project
that enables a language by not displaying the policy warning by default.
Add variable CMAKE_POLICY_WARNING_CMP<NNNN> to control the warning
explicitly; otherwise enable the warning with --debug-output or --trace.
This breaks with strict policy convention because it does not provide
developers with any warning about the behavior change by default.
Existing projects will continue to build without a warning or change in
behavior. When a developer changes the minimum required version of
CMake in a project to a sufficiently high value (3.0), the project will
suddenly get the new compiler id and may break, but at least the
breakage comes with a change to the project rather than the version of
CMake used to build it.
Breaking strict policy convention is worthwhile in this case because
very few projects will be affected by the behavior change but every
project would have to see the warning if it were enabled by default.
Some compilers do not recognize that the end of copy_data cannot
be reached and complain that there is no return statement. Clang
warns that there is an unreachable return statement if it appears.
Conditionally add the return statement when not building with Clang.
Fix the VS 11 and VS 12 flag table entries for this flag. It requires
a value in the following argument. Also drop the general "/analyze:"
flag table entry so that such flags will be passed through as plain
additional options. This is necessary because some such options have
following values and some do not but not all have .vcxproj elements
to hold the values.
Add a "UserFollowing" special flag table entry indicator to say that a
flag expects a value in a following argument. Teach cmIDEOptions to
handle such flags.
This will allow the strings to contain generator expressions.
At this point, generator expressions are still not part of the
SOURCES property when it is read.
Drop the CMAKE_NO_QUOTED_OBJECTS internal variable from the Makefile
generators. The underlying problem is with the Watcom linker, not with
WMake. The Watcom linker wants object files to be single-quoted. Add
<LINK-RULE>_USE_WATCOM_QUOTE platform information variables to tell the
generators to use Watcom-style single quotes for object files on link
lines.
On Windows, Watcom uses the GetCommandLine API to get the original
command-line string and do custom parsing that expects single quotes.
On POSIX systems, Watcom approximates the original command line by
joining all argv[] entries separated by a single space. Therefore we
need to double-quote the single-quoted arguments so that the shell does
not consume them and they are available for the parser to see.
Fix cmOSXBundleGenerator::CreateCFBundle to place Info.plist under the
same root directory as the rest of the bundle. Without this, Info.plist
was placed into CMAKE_BINARY_DIR, not CMAKE_CURRENT_BINARY_DIR because
the target path was not generated correctly.
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.
Not everything that isn't MSVC is GCC. I have support for LDC's depfile
format on its way upstream[1], but its future is uncertain. CMake should
at least support this for future depfile formats.
[1]https://github.com/martine/ninja/pull/721
64c2342a Watcom: Enable 'WMake Makefiles' generator on Linux
5d9aa66c Watcom: Introduce OpenWatcom compiler id and fix compiler version
9292d3b8 Watcom: Detect compiler target architecture and platform
fbc883c9 Watcom: Add one blank line to Makefile for better readability
Rely on evaluation in cmCustomCommandGenerator for the generators.
When tracing target dependencies, depend on the union of dependencies
for all configurations.
Distinguish "Open Watcom" from old "Watcom" by introducing a new
"OpenWatcom" compiler id. The __WATCOMC__ format is "VVRP" for Watcom
and "VVRP + 1100" for Open Watcom.
Curl makes progress callbacks frequently but we round to the nearest
percent and report only when that changes so that we make at most 101
progress reports. However, when unexpected data beyond the total are
transferred the progress can get beyond 100% and lead to unlimited
reports. Avoid this case by capping the reported progress to 100%.
ea17a03b cmTarget: Port <CONFIG>_LOCATION support to updated string APIs
6e466c6f Merge branch 'master' into CONFIG-LOCATION-CMP0026
c903b531 cmTarget: Restore <CONFIG>_LOCATION to CMP0026 OLD behavior (#14808)
ee8cef87 Encoding: If configured, write Visual Studio project files as UTF-8.
91fd99b8 Encoding: Provide option to configure CMake to use UTF-8 encoding.
Restore support for the undocumented <CONFIG>_LOCATION target property
removed by commit v3.0.0-rc1~175^2 (cmTarget: Remove support for
<CONFIG>_LOCATION property, 2013-12-30) as part of the CMP0026 OLD
behavior.
Override the QT_QTMAIN_LIBRARY cache variable with a regular
variable in the Qt 5 configuration. This avoids linking with the
Qt 4 version of the WinMain library.
Implement it in terms of the ComputeObjectFilenames virtual method
on the local generators.
Remove the reimplementation from the global generators which are
now all functionally identical.
Add a CPACK_DEBIAN_COMPRESSION_TYPE option to set the compression type.
Default to 'gzip' to preserve existing behavior. Use "cmake -E tar"
for 'gzip', 'bzip2', and 'none'. Use system "tar" for 'lzma' and 'xz'.
By default, Intel compiler coverage tools generate HTML files as
reports, but the option -txtlcov can be given to codecov to output a
coverage file with LCov format.
To use Intel coverage:
* build the project with coverage flags
* run the application
* run profmerge
* run codecov
The output file will be "build_dir/CodeCoverage/SRCFILEDIR.LCOV".
Ask users to compile with -prof-dir${BUILD_DIR} instead of searching
the entire build tree recursively to find coverage files.
bc993f27 Generalize cmCustomCommandGenerator to more fields
9a5c5544 cmGlobalXCodeGenerator: Simplify handling of multiple outputs
d45e7f34 cmCustomCommand: Return std::string from GetWorkingDirectory
Because we already call [to|from]Local8Bit() with C strings where we are supposed to,
we do not need to specify UTF-8 encoding when converting C strings to QString.
Until now the cmCustomCommandGenerator was used only to compute the
command lines of a custom command. Generalize it to get the comment,
working directory, dependencies, and outputs of custom commands. Update
use in all generators to support this.
Since commit 1a1b737c (stringapi: Use strings for generator names,
2014-02-24) cmExternalMakefileProjectGenerator::CreateFullGeneratorName
expects a std::string instead of const char*. When no extra generator
name is available, pass an empty string to avoid NULL dereference.
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.
* The '-e' option has nothing to do with verbose output.
It is now properly handled by .ERASE directive in make file
* The '-s' option sets silent output globally, it cannot be switched off.
It is now handled only by .SILENT directive in make file directive
is simply controlled by a conditonal block.
Remove SilentNoColon member variable as it is no longer needed.
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.
b633b263 CPackWiX: Fix test to build with expected config
191f25e2 stringapi: Prevent a NULL dereference in WiX
219d6ad6 speedup: Avoid excess iterator dereferences
caaad357 speedup: Cache strings for comparisons
7abf4e31 stringapi: Use strings for dependency information
94fc63e2 stringapi: Use strings for cache iterator values
85fc9f26 stringapi: Command names
6557382d stringapi: Use strings for program paths
1a1b737c stringapi: Use strings for generator names
24b5e93d stringapi: Use strings for directories
11ed3e2c stringapi: Add string overload for the Def struct
b3bf31a5 stringapi: Miscellaneous char* parameters
5af95c39 typo: Match argument name with the header
2b17626e stringapi: Pass strings as install directories in CPack
3def29da stringapi: Use strings for feature arguments
acb116e3 stringapi: Return a string reference for the configuration
...
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.
Most of these are turned into strings in the body of the method
(multiple times in some cases). Accept strings to simplify the API and
keep string construction down.