232a6883 Help: Add release notes for target-language-genex.
9e168941 File(GENERATE): Process genex evaluation files for each language.
b734fa44 Genex: Allow COMPILE_LANGUAGE when processing include directories.
0b945ea9 Genex: Allow COMPILE_LANGUAGE when processing compile definitions.
5c559f11 Genex: Enable use of COMPILE_LANGUAGE for compile options.
e387ce7d Genex: Add a COMPILE_LANGUAGE generator expression.
4a0128f4 VS6: Compute CMAKE_*_FLAGS and COMPILE_DEFINITIONS* only when needed
In commit v3.2.0-rc1~272^2~2 (Makefile: Fix rebuild with multiple custom
command outputs, 2014-12-05) we changed the generated makefile pattern
for multiple outputs from
out1: depends...
commands...
out2: out1
to
out1 out2: depends...
commands...
This was based on the incorrect assumption that make tools would treat
this as a combined output rule and run the command(s) exactly once for
them. It turns out that instead this new pattern is equivalent to
out1: depends...
commands...
out2: depends...
commands...
so the commands may be run more than once.
Some documents suggest using a "dedicated witness" stamp file:
stamp: depends...
rm -f stamp
touch stamp.tmp
commands...
mv stamp.tmp stamp
out1 out2: stamp
However, if the commands fail the error message will refer to the stamp
instead of any of the real outputs, which may be confusing to readers.
Also, this approach seems to have the same behavior of the original
approach that motiviated the above commit: multiple invocations are
needed to bring consumers of the outputs up to date.
Instead we can return to the original approach but add an explicit
touch to each extra output rule:
out1: depends...
commands...
out2: out1
touch -c out2
This causes make tools to recognize that all outputs have changed and
therefore to execute any commands that consume them.
Port some existing cmJoin to use it.
cmJoin is cumbersome to use in cases where the objective is to
somehow 'quote' each item and then join it with a separator. In that
case, the joiner string is harder to read and reason about. cmWrap
aims to solve that.
Provide an overload taking char wrappers to simplify the case
of surrounding every element in quotes without needing to escape
the quote character.
7c3f6376 Convert loop into two algorithms.
8a399c8c Convert loop to the common pattern.
abfca975 Move loop inside of condition.
0b61b86d Handle last element outside of the loop.
e21f7829 cmTarget: Use a sorted vector in place of a set.
559dc155 cmSet: Replace loop with cmJoin.
0ea71932 cmFindBase: Replace loop with cmJoin on range.
9380e85f Convert loops to cmJoin algorithm with cmRange.
bb10012f cmStringCommand: Accumulate with cmJoin and range adaptors.
0c12f1ea cmAlgorithms: Add a range adaptor and API for adjusting a range.
27c6f017 Use cmJoin to accumulate string ranges.
4e78ebbd cmAlgorithms: Add a Range container and adaptor method.
89102249 Replace common loop pattern with cmJoin
7b8725bf Convert loops populating maybe-empty content into the common pattern.
7ee56f03 Convert loops into the commonly used pattern.
0a4e5674 cmMacroCommand: Remove counting variable.
...
d8639733 cmSystemTools: Remove unnecessary comparison.
803317aa cmSystemTools: Early return if size makes later comparison false.
11093a03 Replace temporary bool by inlining warning condition.
6cd2ee95 Replace loop with member algorithm.
94e993a0 cmComputeLinkDepends: Remove temporary iterator copy.
69dbe51b Replace loop with algorithm.
683fafea Replace a loop with std::transform.
63f584b6 Replace while loop with member insert.
74c4d9d2 Take a size check outside of an inner loop.
71d47115 Use insert member instead of back_inserter.
39622c99 Convert while loop to member insert.
a7fcc148 Convert loop to algorithm.
d46c4f07 Extract a prefix variable from loop.
d59913f0 Take computation out of loop.
3f3db744 cmMakefile: Remove ExpandSourceListArguments.
bd990c80 Remove use of ExpandSourceListArguments.
...
Replace use of separate "cmake -E cmake_progress_report" and "cmake -E
cmake_echo_color" commands to report the progress and message portions
of build output lines with --progress-* options to the latter to print
everything with a single command. The line buffering of the stdout FILE
stream should cause the whole line to be printed with one atomic write.
This will avoid inter-mixing of line-wise messages from different
processes during a parallel build.
In commit v3.0.0-rc1~222^2 (Makefile: Allow "gmake target1 target2 -j",
2013-12-18) we added generation of a .NOTPARALLEL rule and told the
generator it is "symbolic" because the file will never be created.
This causes ".PHONY" to be used. However, "clearmake" does not support
parsing of .PHONY specifically for .NOTPARALLEL, so simply drop it.
This should not affect the role of the .NOTPARALLEL rule for GNU make.
Given a rule of the form
out1 out2: dep1
out1 out2: dep2
Borland Make complains that there are multiple rules for "out1"
even though this works when there is only one output. Instead
generate
out1 out2: dep1 dep2
for Borland Make, but only when there are multiple outputs.
Fix the generated makefiles for custom commands with multiple outputs to
list all the outputs on the left hand side of the build rule. This is
much simpler and more reliable than the old multiple-output-pair
infrastructure.
The checks are now split into languages that are able to generate
assembly listings, languages that are able to generate preprocessed
listings, and languages that are able to export the compile commands.
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.
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.
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.
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
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.
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.
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.
Add the .NOTPARALLEL target to each local Makefile command-line
interface entry point file so that even with -j we launch only
one "make -f Makefile2" at a time. The actual build rules
in Makefile2 and lower will still run in parallel.
Do not add .NOTPARALLEL for Borland or Watcom make tools because
they do not tolerate it. Other make tools that do not understand
.NOTPARALLEL will not be hurt.
Suggested-by: Robert Luberda <robert-cmake@debian.org>
Commit b04f3b9a (Create make rules for INTERFACE_LIBRARY
targets., 2013-08-21) extended the makefile generator to create
build targets for INTERFACE_LIBRARY targets. No other generators
were extended with this feature.
This conflicts with the feature of whitelisting of target properties
read from INTERFACE_LIBRARY targets. The INTERFACE_* properties
of the INTERFACE_LIBRARY may legitimately contain TARGET_PROPERTY
generator expressions for reading properties from the 'head target'.
The 'head target' would be the INTERFACE_LIBRARY itself when creating
the build rules for it, which means that non-whitelisted properties
would be read.
This was missing from commit c34968a9 (Port some of the generator
API to cmGeneratorTarget., 2012-10-10). The generator targets
stored with the cmMakefile include IMPORTED targets, unlike the
accessor for resgular targets. Before this patch, rules would
be generated for Qt5::Core for example, which result in broken
makefiles.
As an INTERFACE_LIBRARY has no direct link dependencies, we can
short-circuit in cmGeneratorExpressionEvaluator and
in cmGlobalGenerator::CheckLocalGenerators.
As they do not generate any output directly, any generate- or install-
related code acn also be short-circuited. Many of the local generators
already do this.
Because only INTERFACE related properties make sense on INTERFACE_LIBRARY
targets, avoid setting other properties, for example via defaults.
Just enough to reach the BuildMacContentDirectory method and the
NeedRelinkBeforeInstall methods.
In the future, those methods can be moved to cmGeneratorTarget.
Refactor edit_cache tool selection to ask each global generator for its
preference. Teach the Ninja generator to always use cmake-gui because
Ninja by design cannot run interactive terminal dialogs like ccmake.
Teach the Makefile generator to use cmake-gui when also using an "extra"
generator whose IDE has no terminal to run ccmake, and otherwise fall
back to CMAKE_EDIT_COMMAND selection for normal Makefile build systems.
The result is that the depends of the target are created.
So,
add_library(somelib foo.cpp)
add_library(anotherlib EXCLUDE_FROM_ALL foo.cpp)
add_library(extra EXCLUDE_FROM_ALL foo.cpp)
target_link_libraries(anotherlib extra)
add_library(iface INTERFACE)
target_link_libraries(iface INTERFACE anotherlib)
Executing 'make iface' will result in the anotherlib and extra targets
being made.
Adding a regular executable to the INTERFACE of an INTERFACE_LIBRARY
will not result in the executable being built with 'make iface' because
of the logic in cmComputeTargetDepends::AddTargetDepend.
So far, this is implemented only for the Makefile generator. Other
generators will follow if this feature is possible for them.
Make INTERFACE_LIBRARY targets part of the all target by default.
Test this by building the all target and making the expected library
EXCLUDE_FROM_ALL.
The commits 9db31162 (Remove CMake-language block-end command
arguments, 2012-08-13) and 77543bde (Convert CMake-language
commands to lower case, 2012-08-13) changed most cmake code
to use lowercase commands and no parameters in termination
commands. However, those changes excluded cmake code generated
in c++ by cmake.
Make a similar style change to code generated by cmake.
Drop the "vsProjectFile" argument from cmTarget::TraceDependencies. It
appears to be the modern equivalent to a hunk added in commit ba68f771
(...added new custom command support, 2003-06-03):
+ name = libName;
+ name += ".dsp.cmake";
+ srcFilesToProcess.push(name);
but was broken by refactoring at some point. The current behavior tries
to trace dependencies on a source file named the same as a target, which
makes no sense. Furthermore, in code of the form
add_executable(foo foo.c)
add_custom_command(OUTPUT "${somewhere}/foo" ... DEPENDS foo)
the "vsProjectFile" value "foo" matches source "${somewhere}/foo.rule"
generated to hold the custom command and causes the command to be added
to the "foo" target incorrectly.
Simply drop the incorrect source file trace and supporting logic.
The API for retrieving per-config COMPILE_DEFINITIONS has long
existed because of the COMPILE_DEFINITIONS_<CONFIG> style
properties. Ensure that the provided configuration being generated
is also used to evaluate the generator expressions
in cmTarget::GetCompileDefinitions.
Both the generic COMPILE_DEFINITIONS and the config-specific
variant need to be evaluated with the requested configuration. This
has the side-effect that the COMPILE_DEFINITIONS does not need to
be additionally evaluated with no configuration, so the callers can
be cleaned up a bit too.
As INTERFACE_COMPILE_DEFINITIONS are now possible, we can have
situations like this:
add_library(foo ...)
add_library(bar ...)
target_link_libraries(foo bar)
target_compile_definitions(bar INTERFACE SOME_DEF)
The INTERFACE_COMPILE_DEFINITIONS of bar determine how foo should be
compiled, and if they change, foo should be rebuilt.
Additionally, as of commit d1446ca7 (Append the COMPILE_DEFINITIONS
from the Makefile to all targets., 2012-09-17), we don't need to
read definitions from the makefile if we read them from the target,
so also de-duplicate the cached info.
The DependInfo for INTERFACE_INCLUDE_DIRECTORIES is already handled
correctly.
This is for consistency throughout cmake. The cmsys version exists
becaues uses of auto_ptr types as return types does not work with
some implementations in ancient compilers.
The code handling IMPLICIT_DEPENDS was only able to track a single file,
the latest file replaced earlier files in the list.
The documentation now mentions that the language has to be prefixed to
every file and the test now uses two implicit dependencies, where only
the second is modified to trigger re-running of the custom command.
Alex
Inspired-by: Michael Wild <themiwi@users.sourceforge.net>
Since commit c8ef6430 (Allow directory names containing '=' and warn if
necessary, 2012-02-06) we allow directories with '=' instead of
rejecting them as was previously done since commit 8704525f (Reject
directory names containing '=', 2011-01-14). However, we did not warn
in all cases that '=' may cause failure, such as when it appears on the
right-hand side of a dependency line.
Both commits above were made assuming that '=' cannot be escaped in Make
syntax, but it can be achieved with a variable:
EQUALS = =
left$(EQUALS)side : right$(EQUALS)side
Use this approach to escape '=' in dependency lines, thus supporting
the character in paths.
All our tests now pass when CMake is built in source and build trees
both containing '=', except for the "OutOfSource" test. It fails in
its coverage of the obscure "OutOfBinary" test case where part of the
build tree is located outside the main build tree of the test. The
reason is that CMake must invoke a command like
$(MAKE) -f /path/with=sign/build.make /path/with=sign/somefile
but the make tool interprets the last argument as a variable assignment.
This is an acceptable limitation, since the case is so obscure, in
exchange for supporting '=' cleanly otherwise.
Add a virtual cmGlobalGenerator::ComputeTargetObjects method invoked
during cmGeneratorTarget construction. Implement it in the Makefile
generator to pre-compute all object file names for each target. Use
the results during generation instead of re-computing it later.
Remove partial implementation added by commit ca0230a3 (check in initial
conv library stuff, 2007-02-16) since it was never finished. It does
not make sense for multi-configuration generators since no specific
build configuration is processed at CMake time.
Eliminate callers of cmMakefile::GetIncludeDirectories.
All callers of GetIncludeDirectories should go through the local generator
object.
Only the local generator calls cmTarget::GetIncludeDirectories directly.
The approach taken by commit 8704525f (Reject directory names containing
'=', 2011-01-14) was perhaps too heavy-handed for avoiding the obscure
cases when '=' in the path fails due to limitations of Make syntax.
Only two CMake tests:
LinkDirectory
OutOfSource
fail when the path contains '=' and they cover obscure cases. Instead
of rejecting such paths outright just warn when the problem may occur.
Now also CMAKE_ASM_INCLUDE_PATH is written into
CMakeDirectoryInformation.cmake, which is necessary to make
the dependency scanning for included files work.
Alex
The Watcom WMake tool has trouble running commands in paths that have
parentheses. We already convert most commands to a shortpath for Watcom
if the path contains a space, but the use of $(CMAKE_COMMAND) hides the
true path from that conversion. Factor the shortpath conversion code
out into a new ConvertShellCommand method. Teach it to convert paths
that contain parentheses as well as spaces. Use the new method to
convert the value of $(CMAKE_COMMAND) and other helper variables.
Files for the ASM language are those assembler files which are processed
by the C/CXX compiler, and they may contain preprocessor directives, so
run the C dependency scanner also on them.
Alex
If you had a + in the name of a target with nmake, it created a variable
in the makefile that used + in its name, which is not allowed by nmake.
To make the implementation easier, + is now not allowed for any make
generators as part of a variable name.
The workaround added by commit 7e92f0b4 (Hack to make echo command work
properly in mingw32-make, 2006-10-05) and updated by commit 69356d8a
(Juse use cmake -E echo instead of the native echo, 2006-10-13) no
longer seems necessary with modern mingw32-make. Furthermore it slows
performance due to the time spent loading a cmake process instead of
plain echo.
The parent commit assumed that "cd /d" would work in all Windows shells.
While all modern versions of windows have shells that support it, the
shells used by NMake and Borland make do not. Borland make does not
seem to even support changing drive letters with "d:". Just revert the
feature for all make tools except MinGW where the shell is known to
support this feature.
Teach cmLocalUnixMakefileGenerator3::CreateCDCommand to change working
directories for make tools using a Windows shell using "cd /d" instead
of just "cd". This tells the shell to change the current drive letter
as well as the working directory on that drive.
Commit abaa0267 (When the working directory for a custom command is on
another drive..., 2007-12-17) fixed the same problem for VS IDE
generators as reported by issue #6150.
Create platform option CMAKE_<lang>_USE_RESPONSE_FILE_FOR_INCLUDES to
enable use of response files for passing the list of include directories
to compiler command lines.
Stephen Kelly
Brad King
Nils Gladitz
Tim Gallagher
Ben Boeckel
Jiri Malak
Clinton Stimpson
Andreas Mohr
Alex Neundorf
David Cole
Bill Hoffman