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
The commit "Test all target types in Fortran" enabled a SHARED library
in the Fortran test. However, we do not yet implement support for
shared libraries with XL Fortran (it seems this requires using the C
compiler to link). Furthermore, the old g77 2.97 from Red Hat does not
support shared libs on Itanium because the g2c lib is not -fPIC.
For now we just disable SHARED libs in the test for these tools.
We add Intel and MinGW Fortran linker options to create the import
library portion of a DLL. This allows other binaries to link to a
Fortran DLL.
We also update the Fortran test to use a .def file to specify exports
since there is no __declspec(dllexport) markup syntax in Fortran.
The commit "Set version info for shared libs on OSX" taught the Xcode
generator to honor VERSION and SOVERSION properties. However, it also
set version '1.0.0' as the default when no version property is set,
which is inconsistent with the Makefiles generator. This commit fixes
the default to '0.0.0' for consistency.
See issue #9773.
The reverted commit attempted to preserve the "../" PREFIX work-around
for avoiding per-config build directories in the VS IDE generators.
However, the original reporter has concluded that a "../" PREFIX no
longer works everywhere in VS 10 project files anyway. Rather than set
OutputPath, this commit restores the $(OutDir)$(TargetName)$(TargetExt)
default.
See issue #9768.
This commit fixes the cmparseMSBuildXML.py script to generate correct
flag table entries for booleans with optional value. These flags use
two entries: the first should ignore the value and enable the option,
and the second should use the value if given. Previously the first
entry did not recognize flags with values.
In particular this fixes flags like /MP4, but the change corrects
matching of some other flags too. See issue #9771.
This commit teaches the VS 10 generator to detect the -D_UNICODE option
in preprocessor definitions and set the CharacterSet attribute to the
value 'Unicode'. This was already done for other VS IDE versions.
See issue #9769
The default $(OutDir)$(TargetName)$(TargetExt) for this value works in
most cases because we set the three properties. However, if the target
property PREFIX contains a path component (not documented but happens to
work in other VS generators) we drop it from TargetName and do not put
it in OutDir either. This commit corrects the resulting path by setting
the OutputPath property explicitly with the full path.
See issue #9768.
This commit teaches CMake about the g95 compiler from
http://www.g95.org
We use 'G95' as the compiler id string, and add some basic flags.
See issue #9241.
Intel Fortran on Mac OS X enables Fortran support in Xcode. This commit
teaches CMake to associate Fortran sources properly in Xcode projects.
See issue #9739.
The VS 10 flag table generation script did not produce correct entries
for precompiled header flags. Since precompiled header flag translation
requires multiple entries cooperating in a certain order, it is not
worth the time to make the generation script work automatically. This
commit manually adds the proper entries.
See issue #9753.
MS changed the location of the Microsoft.Cpp.$(Platform).user.props
file. This commit teaches the VS 10 generator about the new location.
See issue #9759.
Versioned UNIX libraries and executables produce multiple names for a
single target using one of
cmake -E cmake_symlink_library
cmake -E cmake_symlink_executable
to create symlinks to the real file for the extra names. However, when
cross-compiling from Windows to Linux we cannot create symlinks. This
commit teaches CMake to make copies instead of symbolic links when
running on windows. While this approach does not produce exactly what
Linux wants to see, at least the build will complete and the binary will
run on the target system. See issue #9171.
During installation of a target we generate "tweak" rules to update the
installed file (RPATH, strip, ranlib, etc.). However, some targets
install multiple files, such as the versioned names of a shared library.
Previously the extra files for a target have always been symbolic links,
but for cross-compiling from Windows to UNIX they may need to be copies.
This commit teaches the generated install scripts to loop over all files
installed for the target to apply tweaks to those that are not symlinks.
See issue #9171.
In cmInstallTargetGenerator::GenerateScriptForConfig we were computing
the full 'from' paths for all target files to be installed, but only
computing a 'to' path for the "main" target file. This commit teaches
the method to compute both 'from' and 'to' paths for every target file
to be installed. The result is cleaner, easier to follow, and will
allow installation tweaks to be added later on all target files.