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.
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.
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.
We revert commit "Create CMake Policy CMP0015 to fix set(CACHE)" because
the NEW behavior of the policy breaks a valid use case:
# CMakeLists.txt
option(BUILD_SHARED_LIBS "..." ON)
add_library(mylib ...)
set(BUILD_SHARED_LIBS OFF) # we want only mylib to be shared
add_subdirectory(ThirdParty)
# ThirdParty/CMakeLists.txt
option(BUILD_SHARED_LIBS "..." ON)
# uh, oh, with NEW behavior this dir uses shared libs!!!
We'll re-introduce the policy later with a different change in behavior
to resolve the motivating case, which was more subtle but less common.
See issue #9008.
The commit "Really fix color check for dependency scanning" disabled
color unless "make COLOR=ON" is specified. This restores the previous
default behavior when CMAKE_COLOR_MAKEFILE is ON while retaining the
previous commit's fix. See issue #9680.
The commit "Fix color check for dependency scanning" was meant to
disable color if CMAKE_COLOR_MAKEFILE was off. It did remove use of the
activation option '--color' but it failed to make the default false when
the option was missing. This commit corrects that. See issue #9680.
The commit "add support for borland run time flag for shared builds"
started using the value of CMAKE_SHARED_LIBRARY_CXX_FLAGS to link
executables because Borland requires some flags both at compile and link
time. This change ended up propagating all the way to the current
Makefile generators and the behavior applies on all platforms.
In general it is incorrect to use these flags to link executables. The
commit "Split Borland compiler information files" re-wrote Borland
support to work without this behavior, so we remove it in this commit.
Patch from Ben Hutchings. See issue #9659.
This commit re-writes Borland compiler build rules. We split the rules
into modern <os>-<id>-<lang> information modules but share a common
macro between languages to avoid duplication.
We also address a bug in the previous rules that would build some target
types against the static Borland runtime and others against the shared
Borland runtime in one build tree. Now we always use the shared runtime
as is the default in the rules for MS tools.
When <pkg>_DIR is set to an incorrect version we search again and store
the result in the variable, even if it is <pkg>_DIR-NOTFOUND.
There was a bug in the case when the new search does not find anything
and the old value came from a cache entry with UNINITALIZED type. The
command used to try to load a package configuration file from the last
place searched, and would leave the old wrong value in the entry. This
commit fixes the behavior to avoid trying to load a missing file and to
set the value to <pkg>_DIR-NOTFOUND as expected.
In cmMakefile::AddCacheDefinition we collapse paths specified in PATH or
FILEPATH cache entries originally specified on the command line with
UNINITALIZED type. This commit fixes the logic to avoid collapsing
<var>-NOTFOUND and other false values. The change allows other CMake
code to force a NOTFOUND value on an entry with UNINITALIZED type.
The commit "Support more special characters in file(STRINGS)" added code
using a 'char' literal as an array index. Some compilers warn about
this because char might be a signed type, leading to negative indices.
We replace the literal with an integer to avoid the warning.
The commits "Teach Fortran compiler identification about the Portland
Group compiler" and "Fix previous change to file(STRINGS) command"
taught file(STRINGS) to recognize the form-feed '\f' character as part
of string literals. The Portland Group Fortran compiler also puts 0x14
bytes at the end of string literals in some cases. We generalize the
previous solution and add the new character in this commit.
Scanning the dependencies for kdelibs/khtml/ (when all files are scanned) is
now down to 4.6 s from 6.3 s before this change (without the
headerLocationCache it takes about 14 s here).
It doesn't really make sense to include the complete include path as part
of the key for the map, since the include path will be the same for
all files in a project, so it doesn't add anything.
Alex
In cmGlobalGenerator::GetTargetSets we collect targets from all local
generators in a tree or subtree corresponding to a project() command.
Some targets, such as ALL_BUILD, are duplicated in each subdirectory
with a project() command. For such targets we should keep only the copy
for the top-most (root) local generator.
Previously this filtering was done in each VS IDE generator, but it is
easier to do it in one place when the targets are first encountered.
This also fixes bad ALL_BUILD dependencies generated for VS 7.0 because
the cmGlobalVisualStudio7Generator::WriteTargetDepends method was not
filtering out duplicates. Now we avoid duplicates from the start.
The commit "Target copy ctor should copy internal state" created a new
cmTargetInternals constructor but failed to initialize a POD member that
the original constructor initializes. This commit fixes it.
Ideally we should never copy cmTarget instances, but it is a pain to
remove current uses of it. The pimplized portion of cmTarget has mostly
members that cache results, but some are part of the object state.
These should be copied in the copy ctor instead of re-initialized.
The Encoding key is now deprecated by the FreeDesktop standard and all
strings are required to be encoded in UTF-8. This desktop entry
explicitly specified an Encoding of UTF-8, which is harmless but no
longer necessary. See
http://standards.freedesktop.org/desktop-entry-spec/1.0/apc.html
for details. Patch from Modestas Vainius. See issue #9659.
In cmTarget we compute the link implementation, link interface, and link
closure structures on-demand and cache the results. This commit teaches
cmTarget to invalidate results after a LINK_INTERFACE_* property changes
or a new link library is added. We also clear the results at the end of
the Configure step to ensure the Generate step uses up-to-date results.
In cmTarget::SetProperty and cmTarget::AppendProperty we check whether
changing the property invalidates cached information. The check was
duplicated in the two methods, so this commit moves the check into a
helper method called from both.
This method is called during ConfigureFinalPass on every target. It
gives each target a chance to do some final processing after it is known
that no more commands will affect it. Currently we just call the old
AnalyzeLibDependencies that used to be called directly.
This commit re-words the warning message produced for CMP0012 to avoid
the word 'you' since often the person reading the message is not the
author of the code. We also add an example of the bad OLD behavior to
the policy documentation.
These policies were originally developed during the 2.7.x series and
intended for 2.6.5. There was never a 2.6.5 release, so we should refer
to 2.8.0 instead.
This commit creates target and directory properties to enable the Intel
interprocedural optimization support on Linux. Enabling it adds the
compiler option '-ipo' and uses 'xiar' to create archives.
See issue #9615.
This creates cmTarget::GetFeature and cmMakefile::GetFeature methods to
query "build feature" properties. These methods handle local-to-global
scope and per-configuration property lookup. Specific build features
will be defined later.
We create cmMakefileTargetGenerator::AddFeatureFlags to consolidate
addition of language flags. Currently it just adds the flags from
generic per-language flag variables (AddLanguageFlags).
There is confusion whether the file "currently being processed" inside a
function or macro is the file containing the definition or not. This
commit explicitly describes the behavior. See issue #9646.
In VS 6, 7, and 7.1 solutions we implement
add_dependencies(myexe mylib) # depend without linking
by creating an intermediate mylib_UTILITY target with dependencies
myexe -> mylib_UTILITY -> mylib
to avoid linking myexe to mylib. Previously these extra targets were
only added to the solution files in an ancestor directory of that
defining mylib. For example, in the project:
# CMakeLists.txt
project(TOP)
add_subdirectory(A)
add_subdirectory(b)
# A/CMakeLists.txt
add_library(mylib ...)
# B/CMakeLists.txt
project(B)
add_executable(myexe ...)
add_dependencies(myexe mylib)
the solution for TOP would have mylib_UTILITY but the solution for B
would not even though it pulls in mylib through the dependency. This
commit fixes solutions generated in other directories so that any
solution that has mylib will get mylib_UTILITY also.
See issue #9568.