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.
This will allow additional information about the availability
and capabilities of extra generators to be queried without
actually creating them.
Instead of a static NewFactory() method like the main generator
factories have, use a static GetFactory() method to get a pointer to a
statically allocated extra generator factory. This simplifies memory
management.
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.
SublimeClang is a optional plugin to SublimeText and I felt it
shouldn't be part of the generator for the following reasons:
1. Reduces the amount of sublime and sublimeClang specific
code we have to maintain inside CMake.
2. In testing the SublimeClang commands generated did not work
for the VTK project.
For people that do want this feature I recommend that they
looking into https://gist.github.com/robertmaynard/4724705 for a
way to use CMAKE_EXPORT_COMPILE_COMMANDS to generate JSON files
that can be used by SublimeClang.
The sublimeclang_options_script property is now set in the project
file. It is set to execute a python script that reads the JSON options
file to get options per source file. Python must be installed and in the
path for this feature to work from Sublime Text.
We no longer write sublimeclang_options to the project file, but instead
write a separate .sublimeclang-options JSON file that contains a map
of source file paths to compile flags for that file.
Both define and include flags from CMAKE_C(XX)_FLAGS are now included in
SublimeClang options.
Include directories are now used with absolute paths instead of relative
paths since CMake generated build trees cannot be moved anyway.
Changed the the SublimeText2 generator name to Sublime Text 2.
Fixed a minor issue where if the build directory was outside of the source
directory an unnecessary folder_exclude_pattern was generated in the
Sublime Text 2 project file.
This adds -I include path flags and -D define flags for sublimeclang.
The current problem with this is that these flags cannot be set per
target (build_system in sublime text), it can only be set project
wide. Currently all of the include paths and compiler definitions from
ALL of the targets are used (with duplicates removed). This could be
problematic in some cases (conflicting compiler definitions among targets).
The generator adds all list and source files for each defined
project. The generated project files also include build_system
entries that run the platform-specific make on the generated
Makefiles. A build_system entry is created for each target
that was defined in the CMakeLists.txt files.
At the moment this has only been tested with C/C++ projects.