Per-source copyright/license notice headers that spell out copyright holder
names and years are hard to maintain and often out-of-date or plain wrong.
Precise contributor information is already maintained automatically by the
version control tool. Ultimately it is the receiver of a file who is
responsible for determining its licensing status, and per-source notices are
merely a convenience. Therefore it is simpler and more accurate for
each source to have a generic notice of the license name and references to
more detailed information on copyright holders and full license terms.
Our `Copyright.txt` file now contains a list of Contributors whose names
appeared source-level copyright notices. It also references version control
history for more precise information. Therefore we no longer need to spell
out the list of Contributors in each source file notice.
Replace CMake per-source copyright/license notice headers with a short
description of the license and links to `Copyright.txt` and online information
available from "https://cmake.org/licensing". The online URL also handles
cases of modules being copied out of our source into other projects, so we
can drop our notices about replacing links with full license text.
Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority
of the replacements mechanically. Manually fix up shebang lines and trailing
newlines in a few files. Manually update the notices in a few files that the
script does not handle.
Call the generator "Visual Studio 15" without any year because the
preview version of VS 15 does not provide a year in the product name.
Copy cmGlobalVisualStudio14Generator to cmGlobalVisualStudio15Generator
and update version numbers accordingly. Add the VS15 enumeration value.
Note that we do not need to add a MSVC15 variable or v150 toolset
because Visual Studio 15 comes with an updated version of the v140
toolset and remains ABI-compatible.
Teach tests VSExternalInclude, RunCMake.GeneratorPlatform, and
RunCMake.GeneratorToolset to treat VS 15 as they do VS 10-14.
Closes: #16143
Run the `Utilities/Scripts/clang-format.bash` script to update
all our C++ code to a new style defined by `.clang-format`.
Use `clang-format` version 3.8.
* If you reached this commit for a line in `git blame`, re-run the blame
operation starting at the parent of this commit to see older history
for the content.
* See the parent commit for instructions to rebase a change across this
style transition commit.
Add a `VS_STARTUP_PROJECT` directory property to specify the project
that should be placed first in the `.sln` file so that it will be
selected as the default startup project.
Co-Author: Taylor Braun-Jones <taylor.braunjones@avigilon.com>
Refactor cmGlobalVisualStudioGenerator::TargetCompare to store the name of
the target that should come first instead of hard-coding "ALL_BUILD".
Update client sites to specify "ALL_BUILD" when ordering for .sln files
and an empty string otherwise (in cases when "ALL_BUILD" should not be
encountered anyway).
8f86407c Windows: Optionally generate DLL module definition files automatically
069aa93b bindexplib: Add support for "/bigobj" format objects
61bbbdcf bindexplib: Fix treatment of some symbols
de70c922 bindexplib: Teach DumpFile to return errors
8ea69dfe bindexplib: Build source as part of CMakeLib
2963cb2a bindexplib: Wrap long lines
4ff09893 bindexplib: Drop code that CMake does not need
7de8276c bindexplib: Add copyright/license notice block
65086ad7 bindexplib: Import original implementation from CERN
Create target property WINDOWS_EXPORT_ALL_SYMBOLS to automatically
generate a module definition file from MS-compatible .obj files and give
it to the linker in order to export all symbols from the .dll part of a
SHARED library.
We never implemented them for VS 11 (2012), 12 (2013), or 14 (2015).
For VS 10 (2010) the reload macro does not work correctly when run from
inside a build launched through the IDE because stopping the build kills
the CMake that is driving the reload. Fortunately VS >= 10 know how to
reload the whole solution anyway.
Make the virtual 'Generate' method protected. Make 'DoGenerate'
the main entry point to generation. This gives cmGlobalGenerator
a chance to do some early operations before the individual
generator-specific implementations take over.
Remove the general infrastructure for these additional platform
definitions and hard-code the only two special cases that used
it. They are only for historical reasons so no new such cases
should be added.
Implement it in terms of the ComputeObjectFilenames virtual method
on the local generators.
Remove the reimplementation from the global generators which are
now all functionally identical.
Casts from std::string -> cmStdString were high on the list of things
taking up time. Avoid such implicit casts across function calls by just
using std::string everywhere.
The comment that the symbol name is too long is no longer relevant since
modern debuggers alias the templates anyways and the size is a
non-issue since the underlying methods are generated since it's
inherited.
When using link_directories() and including CMAKE_CFG_INTDIR,
one can end up with duplicate RPATHs in the binary which
install_name_tool cannot fix without corrupting the binary.
Also, the cmake_install.cmake file has been fixed to correctly
handle these generator specific variables.
Drop the "Modules/CMakeVS*FindMake.cmake" files. Override the
cmGlobalGenerator::FindMakeProgram method for VS generators to use their
internal APIs to locate the build tool. Set the CMAKE_MAKE_PROGRAM as a
normal variable for use by project code, but do not cache it. This will
allow CMake and CTest to select the proper tool at build time.
All generators now support detection of the full path to the compiler, so
require it to be so. This will allow CMake<LANG>Information.cmake and
other logic to assume the full path to the compiler tool is available.
The Makefile generators already rejected CMAKE_<LANG>_COMPILER values
that did not name an existing compiler. Extend this error message to
all generators, make it occur as early as possible, and improve the
message with advice about how to set the compiler. If the full path to
the compiler is not known, finish enabling languages with a fatal error
so configuration does not continue.
For now, allow the RC language compiler to not be a full path. Later we
will need to detect the full path to "rc" under the VS IDE.
Add a RunCMake.CompilerNotFound test to cover failure cases.
Fix the RunCMake.CompilerChange test EmptyCompiler case to work
when configuration does not continue past enable_language.
Since we do not need the information about the target architecture
we can use the PlatformName only to specify the this information.
This also removes setting of the MSVC_*_ARCHITECTURE_ID variable
which is not required, because this variable gets set by the
compiler detection code in CMAKE_DETERMINE_COMPILER_ID_CHECK().
Teach Windows-cl.cmake to use CMAKE_(C|CXX)_COMPILER_VERSION to set the
"MSVC##" and MSVC_VERSION variables. It no longer needs the IDE generator
to dictate the version or to detect the version by running the
command-line tool for NMake and Ninja generators. Drop configuration of
CMakeCPlatform.cmake and CMakeCXXPlatform.cmake from Windows-cl.cmake.in
because all the results it saved are now cheap to compute every time.
Implement cmGlobalGenerator::ComputeTargetObjects in the VS generator
to pre-compute all the object file names. Use the results during
generation instead of re-computing it later.
VS 7.1 and below have 2 behaviors that make the cmComputeTargetDepends
result difficult to use for solution-level dependencies. Update the
method cmGlobalVisualStudioGenerator::ComputeTargetDepends to document
the behaviors and work around them. Commit 1a0c166a (Store direct
dependencies in solutions for VS >= 8, 2010-08-20) isolated VS >= 8 from
this computation so those versions should be unaffected.
This change removes the last use of cmTarget::GetLinkLibraries for
purposes other than backward compatibility with legacy interfaces
(export_library_dependencies, VS 6 custom .dsp templates). Now the
cmComputeTargetDepends results are used for all generators so global
target dependency computation is fully centralized.
Commit 438a7e2f (Fix utility dependencies for static libraries in VS
generators, 2007-04-04) implemented utility-only dependencies between
linkable targets by introducing an intermediate non-linkable target.
We convert a dependency of the form
foo -> bar
to the form
foo -> bar_UTILITY -> bar
to prevent foo from including bar on its link line. Previously we added
the extra "_UTILITY" targets explicitly among the project targets before
dependency analysis was performed. Now we generate them separately at
the last moment so that cmGlobalGenerator need not be aware of them.
Compute VS target dependencies in cmGlobalVisualStudioGenerator when the
main global dependency analysis is done. Use these results in each of
the VS generators instead of duplicating the analysis.
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 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.
Brad King
Tobias Hunger
Kitware Robot
Davy Durham
Stephen Kelly
Bill Hoffman
Ben Boeckel
Clinton Stimpson
Patrick Gansterer
David Cole