Similar incomplete generator expressions are already tested
in the GeneratorExpression unit test, but those are executed
with add_custom_target. The generator expressions in the include
directories are run through the preprocessor, whereas the ones
run through add_custom_target are not.
In commit 2a797539 (FindPNG: improve library detection, 2013-07-27) we
split the search for PNG into separate PNG_LIBRARY_DEBUG and
PNG_LIBRARY_RELEASE variables. However, if a project or user sets the
old PNG_LIBRARY value we must honor it instead of searching.
While at it, mark PNG_LIBRARY_RELEASE and PNG_LIBRARY_DEBUG as advanced
and remove a stray debug message.
CMake's intended interface for linking to explicit object files (marked
with EXTERNAL_OBJECT) is that only those listed as target sources should
be linked. Drop FindCUDA's attempt to hide the .obj files from VS IDE
project files, which depends on VS-version-specific behavior of linking
custom command outputs that happen to be named "*.obj". CMake puts
external object files in a dedicated source group anyway.
The workaround currently present works fine without -O or with -O1, but fails
with -Os or -O2 and higher. Using -O2 is common e.g. in Gentoo, as resulting in
bugs like this:
https://bugs.gentoo.org/473276
Prevent the workaround for higher optimization levels to make bootstrapping
more likely to succeed.
This is still a workaround as ld still keeps crashing in some situations.
In commit fb9f73de (MSVC: Invoke 'link' directly for executables,
2013-04-08) we forgot to remove the /link option handling added by
commit e31df039 (Ninja: move <OBJECTS> in front of the first linker
option, 2012-09-27) to the Platform/Windows-MSVC module. Drop it now.
The version of Intel Fortran that actually uses 9.10 as a project format
is very old. Default to the latest format version (11.0) and use the
older format only when known to be necessary.
Suggested-by: Dick Munroe <munroe@csworks.com>
When compiling the 64 bit version of wxWidgets using nmake the library
folders become vc_x64_lib and vc_x64_dll and can coexist with the win32
version.
We populate and maintain a vector of structs to keep track of
backtraces already, so no need to populate the Properties container
additionally.
For completeness, it is necessary to remove the condition for
populating the vector for only valid library names and generator
expressions. That condition is now determined when evaluating the
generator expressions.
Since commit ad502502 (cmMakefile: Track configured files so we can
regenerate them, 2013-06-18) cmMakefile::ConfigureFile records the
configured file as an output file generated by CMake. The intention is
that for make and ninja we can re-run CMake when one of the files it
generates goes missing. However, files configured temporarily in
CMakeTmp directories by Check* modules do not live past the CMake
invocation.
We have to also track input files to the configure command. In theory
the input to a configure command could it self be a file that is going
to be deleted later (output from a custom command or configure_file).
When the VS IDE build output setting
Tools -> Options -> Projects and Solutions ->
Build and Run -> MSBuild project output verbosity
is set to "Diagnostic" the build output contains a " (TaskId:###)"
suffix on the CMAKE_<lang>_COMPILER= line used to extract the compiler
executable location. Strip this suffix before checking that the
reported location exists.
The feature needs access to all link libraries. In the future that
will only be possible to calculate at generate-time.
Even when the files were generated at configure time, they were
generated after user code in CMakeLists files were generated. No
policy is needed to handle manipulation of the files from CMake
code, because that was never possible.
Stephen Kelly
Brad King
Kitware Robot
Rolf Eike Beer
Alex Neundorf
Clinton Stimpson
Marius Luca
Robert Maynard