In some environments the linker produces warnings like
warning: directory not found for option
warning: object file compiled with -mlong-branch ...
These do not affect the availability of C++ features we're checking,
so filter them out.
Fixes: #17850, #17947
de549083e3 cmVisualStudio10TargetGenerator: warn if /clr flag is set manually
59ec7d50bd cmVisualStudio10TargetGenerator: fix for backward compatibility
663f5120f4 cmGlobalVisualStudioGenerator: remove TargetCanBeReferenced()
359544a907 add tests for using target_link_libraries() with imported managed targets
43571073e0 cmVisualStudio10TargetGenerator: store managed reference information in maps
16fec7e2fc cmVisualStudio10TargetGenerator: make some methods config aware
f3c6828876 cmVisualStudio10TargetGenerator: /clr compatible flags for managed tgt
f9042d807d remove TargetIsCSharpOnly() and use methods from cmGeneratorTarget
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1805
Since its beginning the Ninja generator has handled `GENERATED` source
files that have no custom command producing them by writing a dummy
custom command for them that depends on the target ordering phony edge.
Make the custom command's dependency order-only since the phony edge
also has only order-only dependencies. The dummy custom command
should never be considered "dirty" by `ninja`.
Fixes: #17942
Since commit v3.9.0-rc1~230^2~2 (ninja: break unnecessary target
dependencies, 2017-04-17) we unconditionally generate a phony edge for
target ordering. It is needed in case a later target depends on it.
However, if the phony edge has no inputs then `ninja -d explain` prints:
ninja explain: output ... of phony edge with no inputs doesn't exist
Furthermore the phony edge's output is considered dirty and can cause
dependents to be incorrectly considered dirty. Avoid this by always
generating at least one input to the target ordering phony edges.
If we have no real dependencies just use a path that always exists.
Fixes: #17942
Internally we mark `file(GENERATE)` outputs as `GENERATED` in order
to tell custom command dependency tracing logic not to expect the
files to exist on disk yet. This is because we do not generate the
files until after that tracing is done.
The Ninja generator also interprets the `GENERATED` property to mean
that it is expected that some build rule will generate the file if
another build rule depends on it. If the generator does not know of a
custom command that generates the file then it adds an empty one so that
the `ninja` build tool does not complain about a dependency on a file
that does not exist and has no rule to generate it. However, this step
is not necessary for `file(GENERATE)` outputs because there is no build
rule to generate them and they will exist before `ninja` runs.
Add an additional `__CMAKE_GENERATED_BY_CMAKE` property internally to
tell the Ninja generator that a `GENERATED` file will exist before the
build starts and is not expected to have a build rule producing it.
Fixes: #17942
7d756f37cc FindBLAS: do not write an imported target name into BLAS_LIBRARIES
946846aaf5 FindPkgConfig: do not unset unused variable
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2006
f59c33a763 VS: Generate a custom command only in the least dependent target
d58d4daa6b cmVisualStudio10TargetGenerator: Use cmLocalVisualStudio10Generator
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !1889
Since commit v3.11.0-rc1~177^2 (FindBLAS: optionally query pkg-config
for a library, 2017-12-15) the `BLAS_LIBRARIES` result variable may
incorrectly contain the name of an imported target. Instead store the
list of libraries in the variable. Unfortunately pkg_check_modules does
not provide a way to get this so we need to use a (temporary) hack of
reading `INTERFACE_LINK_LIBRARIES` from the interface library target.
Fixes: #17934
When using https://github.com/cristianadam/cmake-checks-cache I have
noticed that CheckTypeSize would in certain cases have an empty
`__check_type_size_dir` variable. The errors would point to
`TestBigEndian`. By moving `include(CheckTypeSize)` outside the macro,
the errors go away.
Including dependencies of a module when the module is first included is
simpler and cleaner anyway.
