Revert commit 74b1c9fc8e (Explicitly specify language flag when source
LANGUAGE property is set, 2020-06-01, v3.19.0-rc1~722^2) and the lookup
tables from its two immediate ancestors. The purpose of that change was
to convert an explicit `LANGUAGE` source file property into an explicit
language specification compiler flag like `-x c`. This seems reasonable
since the property is documented as meaning "indicate what programming
language the source file is". It is also needed to help compilers deal
with non-standard source file extensions they don't recognize.
However, some projects have been setting `LANGUAGE C` on `.S` assembler
source files to mean "use the C compiler". Passing `-x c` for them
breaks the build because the `.S` sources are not written in C. These
projects should be updated to use `enable_language(ASM)`, for which
CMake often chooses the C compiler as the assembler when using
toolchains that support it (which would have to be the case for projects
using the approach).
Revert the change for now to preserve the old behavior for such projects.
We can re-introduce it with a policy in a future version of CMake.
Fixes: #21469
Issue: #14516, #20716
The `work-directory` field has been moved into individual rules since
each one may correspond to a different compiler invocation and therefore
a different work directory.
Support for arbitrary binary paths has been removed for simplicity.
We now assume paths have a valid UTF-8 round-trip representation.
f3eed2c49d cmGlobalNinjaGenerator: use P1689 dependency file format for Fortran
a02c4ccabc cmScanDepFormat: add reader and writer for the format from P1689R2
fa18069ebd Ninja: Exclude unused dyndep features during CMake bootstrap
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Michael Hirsch, Ph.D. <michael@scivision.dev>
Merge-request: !5485
cfce067b3f Tests: Add RunCMake.Make case for conflicting Makefile names
378c047ae3 Makefiles: Explicitly tell 'make' tool what Makefile name to use
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5509
The PCH header file itself is written by CMake and is not generated by
part of the buildsystem. Therefore the `GENERATED` property is not
appropriate to set because the file is always present before the build
starts. We already do not mark the PCH source file as `GENERATED`
either.
This is a preparation for solving #18399, which will no longer allow to
unset the `GENERATED` property from a source-file once it was set.
Fixes: #21437
Signed-off-by: Deniz Bahadir <dbahadir@benocs.com>
CMake did not specify the filename of the Makefile generated by it.
Due to GNU make precedence rules this means that the presence of a
GNUmakefile or makefile would take precedence over the generated
Makefile.
This is only relevant for in-source builds and only whenever an
alternative makefile by the above mentioned names exists.
This patch adds the (seemingly universal) `-f` switch and the
(hardcoded) filename (it is now hardcoded separately in these two
files):
- cmLocalUnixMakefileGenerator3.cxx
- cmGlobalUnixMakefileGenerator3.cxx
Fixes: #21418
c00a6d3967 MSVC: Do not add /GR to CMAKE_CXX_FLAGS by default
6114c8e994 MSVC: Factor out initialization of /GR flag
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !5508
The `/GR` flag has been on by default since MSVC cl 14.0 from VS 2005.
Remove it from the default flags to make it easier for projects to pass
`/GR-` themselves to turn it off.
Projects may be using string processing to replace `/GR` with another
flag, so we cannot simply drop it. Add a policy to drop it in a
compatible way.
Fixes: #21428
Output like the following is typically not interesting at all:
LINK : program database F:\Project\Project.pdb missing; performing full link
Creating library Project.lib and object Project.exp
Fixes#21422
The Ninja `cleandead` tool does not account for implicit outputs
discovered by `dyndep` bindings and can remove Fortran `.mod` files that
are still needed. Disable the `cleandead` step when using `dyndep`
bindings.
Fixes: #21406
