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.
We factor the implementation of
cmake -E cmake_symlink_library
cmake -E cmake_symlink_executable
out of cmake::ExecuteCMakeCommand into methods
cmake::SymlinkLibrary
cmake::SymlinkExecutable
plus a helper method cmake::SymlinkInternal.
The cmInstallTargetGenerator methods AddStripRule and AddRanlibRule do
not need the target type argument. They can simply use the type of the
target for which the generator instance was created.
The CMAKE_OSX_ARCHITECTURES variable works only as a global setting.
This commit defines target properties
OSX_ARCHITECTURES
OSX_ARCHITECTURES_<CONFIG>
to specify OS X architectures on a per-target and per-configuration
basis. See issue #8725.
Both generators use the CMAKE_EDIT_COMMAND variable to determine whether
they should add the edit_cache target, i.e. they don't add it if it's
ccmake, since this does not work inside the output log view of
Eclipse/Codeblocks. But instead of requiring the variable to be set they now
check it for 0 and handle this appropriately. This should help Dave getting
some testing for them :-)
Alex
In VS 8 and greater this commit implements
add_dependencies(myexe mylib) # depend without linking
by adding the
LinkLibraryDependencies="false"
option to project files. Previously the above code would cause myexe to
link to mylib in VS 8 and greater. This option prevents dependencies
specified only in the solution from being linked. We already specify
the real link library dependencies in the project files, and any project
depending on this to link would not have worked in Makefile generators.
We were already avoiding this problem in VS 7.1 and below by inserting
intermediate mylib_UTILITY targets. It was more important for those
versions because if a static library depended on another library the
librarian would copy the dependees into the depender! This is no longer
the case with VS 8 and above so we do not need that workaround.
See issue #9732.
In Visual Studio project files we pass compiler flags to the whole
target based on the linker language, which works for MS tools and
combinations of C and C++. For the Intel Fortran plugin though the
generated .vfproj files should never contain C or C++ options.
We generate .vfproj files only for targets consisting only of Fortran
code. Now that the linker language is computed transitively through
linking it is possible that the linker language is C++ for an otherwise
Fortran-only project. This commit forces Fortran as the linker language
for the purpose of specifying target-wide flags in .vfproj files.
See issue #9719.
The commit "Avoid non-root copies of root-only targets" moved the check
for root-only targets into cmGlobalGenerator::GetTargetSets to avoid
adding multiple ALL_BUILD targets to the "original" target set. This
approach did not work for ZERO_CHECK targets though because those are
pulled in by dependency analysis.
Instead we eliminate duplicate ZERO_CHECK targets altogether and refer
to a single one from all solution files. This cleans up VS 10 project
file references to ZERO_CHECK targets anyway.
Brad King
David Cole
Bill Hoffman
KWSys Robot
Alexander Neundorf
Zach Mullen
Philip Lowman
Marcus Hanwell