We replace "/MD" with ifort-specific flags as follows:
/MD -> /threads /libs:dll
/MDd -> /threads /libs:dll /dbglibs
We also enable the "/MD" equivalent for all Fortran configurations.
Previously multithreaded dll runtimes were used for release builds and
threaded static runtimes for debug builds. For mixed Fortran C/C++
projects, this led to link warnings for Debug but not for Release.
See issue #8744.
The commit "Test per-config OUTPUT_DIRECTORY properties" added this test
with a find_library() call in a CMake script, which requires an explicit
list of possible library prefixes and suffixes. This commit adds more
suffixes to match the libraries built on HP, MinGW, and Cygwin.
We test (ARCHIVE|LIBRARY|RUNTIME)_OUTPUT_DIRECTORY_<CONFIG> properties
by building COnly as a subdirectory and setting the properties to put
its files in specific locations. We build an executable that verifies
the targets actually appear where expected.
We create per-configuration target properties to specify ARCHIVE,
LIBRARY, and RUNTIME output directories. The properties override the
generic properties for the <CONFIG> configuration:
ARCHIVE_OUTPUT_DIRECTORY -> ARCHIVE_OUTPUT_DIRECTORY_<CONFIG>
LIBRARY_OUTPUT_DIRECTORY -> LIBRARY_OUTPUT_DIRECTORY_<CONFIG>
RUNTIME_OUTPUT_DIRECTORY -> RUNTIME_OUTPUT_DIRECTORY_<CONFIG>
For multi-configuration generators, the per-configuration subdirectory
normally appended to the generic output directory is not added to the
configuration-specific property values. This allows projects to set the
exact location at which binaries will be placed for each configuration.
See issue #9163.
VS 6 forgets to create the output directory for a static library if it
differs from the intermediate files directory. We work around this VS
bug by creating a pre-link event on the library target to make the
directory.
This commit removes use of configuration-less cmTarget::GetDirectory()
by the VS 6 generator (except for compatibility with user templates).
We replace OUTPUT_DIRECTORY_<CONFIG> tokens in the templates using the
per-configuration result of cmTarget::GetDirectory(config).
The try_compile() command's COPY_FILE option should not try to actually
copy the file if it cannot be found. Some C runtime library's fopen
cannot handle an empty file name.
Previously the Xcode generator set SYMROOT to be the target output
directory. This told Xcode to put the "<proj>.build" directory in the
output path too.
This commit sets SYMROOT, CONFIGURATION_BUILD_DIR, and OBJROOT to put
intermediate files in the build directory corresponding to the source
directory that created each target. This is more consistent with the VS
IDE generators. Now only the build output files (actual targets) go to
the target output directory.
The commit "Disable Intel CRT deprecation warnings" broke the logic that
disabled MS's CRT deprecation warnings. This fixes the logic to disable
the warnings for both MSVC and Intel.
The Intel Compiler for Windows uses the MS runtime library which
deprecates many C functions. We define _CRT_SECURE_NO_DEPRECATE and
_CRT_NONSTDC_NO_DEPRECATE to disable the deprecation warnings.
The BuildDepends test exercises incremental linking with MSVC and Intel
tools on Windows. In some cases the Intel compiler creates objects that
cause the MS linker it invokes to crash during incremental linking. We
avoid the problem for this test by disabling incremental linking.
We introduce the "CMake.If" test to try out conversion of constants and
variables to boolean values in the if() command. We cover both OLD and
NEW behavior for policy CMP0012.
The commit "modified the if command to address bug 9123 some" changed
the if() command behavior with respect to named boolean constants. It
introduced policy CMP0012 to provide compatibility. However, it also
changed behavior with respect to numbers (like '2') but did not cover
the change with the policy. Also, the behavior it created for numbers
is confusing ('2' is false).
This commit teaches if() to recognize numbers again, and treats them
like the C language does in terms of boolean conversion. We also fix
the CMP0012 check to trigger in all cases where the result of boolean
coersion differs from that produced by CMake 2.6.4.
The if() command reports its arguments at the beginning of some error
messages. Originally it reported the un-expanded form of the arguments
because in ancient CMake versions no context information was available.
Now it is more useful to see the real arguments, which may be mentioned
in the main error message. Since full context information is now
available, users can refer back to the source if they need to see the
unexpanded form of the arguments.
For example, the code
set(regex "++")
if("x" MATCHES "${regex}")
endif()
now produces the message
if given arguments:
"x" "MATCHES" "++"
Regular expression "++" cannot compile
instead of
if given arguments
"x" MATCHES "${regex}"
Regular expression "++" cannot compile
David Cole
Mathieu Malaterre
KWSys Robot
Will Dicharry
Zach Mullen
Bill Hoffman
Brad King
Dave Partyka
James Bigler
Zack Galbreath