Commit Graph

12 Commits

Author SHA1 Message Date
Kitware Robot d9fd2f5402 Revise C++ coding style using clang-format
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.
2016-05-16 16:05:19 -04:00
Brad King 7c36d2067b cmListFileBacktrace: Refactor storage to provide efficient value semantics
Since commit v3.4.0-rc1~321^2~2 (Genex: Store a backtrace, not a pointer
to one, 2015-07-08) we treat cmListFileBacktrace instances as
lightweight values.  This was true at the time only because the
backtrace information was kept in the cmState snapshot hierarchy.
However, that forced us to accumulate a lot of otherwise short-lived
snapshots just to have the backtrace fields available for reference by
cmListFileBacktrace instances.  Recent refactoring made backtrace
instances independent of the snapshot hierarchy to avoid accumulating
short-lived snapshots.  This came at the cost of making backtrace values
heavy again, leading to lots of string coying and slower execution.

Fix this by refactoring cmListFileBacktrace to provide value semantics
with efficient shared storage underneath.  Teach cmMakefile to maintain
its call stack using an instance of cmListFileBacktrace.  This approach
allows the current backtrace to be efficiently saved whenever it is
needed.

Also teach cmListFileBacktrace the notion of a file-level scope.  This
is useful for messages about the whole file (e.g. during parsing) that
are not specific to any line within it.  Push the CMakeLists.txt scope
for each directory and never pop it.  This ensures that we always have
some context information and simplifies cmMakefile::IssueMessage.
Push/pop a file-level scope as each included file is processed.  This
supersedes cmParseFileScope and improves diagnostic message context
information in a few places.  Fix the corresponding test cases to expect
the improved output.
2016-04-18 09:21:19 -04:00
Stephen Kelly 6da65b3907 Allow export of targets with INTERFACE_SOURCES.
Use the same rules for paths in source and binary dirs in
installed INTERFACE_SOURCES as are used for
INTERFACE_INCLUDE_DIRECTORIES.
2015-02-11 00:51:34 +01:00
Stephen Kelly 1c3918ff02 RunCMake: Remove unneeded files.
The default expectation of RunCMake tests is empty content, so there
is no need to specify it.
2015-02-09 19:15:04 +01:00
Stephen Kelly e134805666 Export: Disallow export of targets with INTERFACE_SOURCES
This can be allowed in the next release, but it needs to have some
features present and tested such as

* Ensuring that relative paths do not appear in the generated property.
* Ensuring that paths to the source or build directories do not appear.
* Generating a check in the file for CMake 3.1 or later so that the
    resulting property will be consumed.
* Ensuring that any referenced targets are part of an export set and
    generating a check for them.
* INSTALL_INTERFACE and BUILD_INTERFACE content.

All of these checks are already done for INTERFACE_INCLUDE_DIRECTORIES,
but it is too late to add them for INTERFACE_SOURCES for CMake 3.1.
As the checks introduce some new error conditions, it is better to
disallow exporting fully for this case and introduce proper error
conditions later instead of policies.
2014-11-29 12:24:59 +01:00
Stephen Kelly bb5905bb13 cmTarget: Don't allow relative paths in INTERFACE_SOURCES
Follow the pattern of checks that are made for INTERFACE_INCLUDE_DIRECTORIES.
Existence is already checked by cmSourceFile::GetFullPath.  Add a check
to disallow relative paths in source directories. Otherwise code such as

 target_sources(lib1 INTERFACE foo.cpp)

would fail if consumed by a target in a different directory.

Unlike the INTERFACE_INCLUDE_DIRECTORIES behavior, we don't care whether
the entry comes from an IMPORTED target or not.  In the include directories
case, the directory for a non-imported target might not exist yet but
might be created.  In the sources case, a file which does not yet
exist in the filesystem must be explicitly marked with the GENERATED
property.

Adjust existing tests and add a new test for the error.
2014-11-29 12:24:59 +01:00
Brad King 0366ba5db6 Tests: Fix RunCMake.TargetSources on Xcode 1.5
Xcode 1.5 does not support multiple configurations.  The generator also
adds some sources internally that cause extra OriginDebug output.
Update the expected output to tolerate it.
2014-06-06 10:28:32 -04:00
Stephen Kelly b8af201168 cmTarget: Fix listing of source files at configure-time.
Since commit e5da9e51 (cmTarget: Allow any generator expression in
SOURCES property., 2014-03-18), source files are computed by
true evaluation of generator expressions, including TARGET_OBJECTS.
This evaluation requires the presence of cmGeneratorTarget objects
since commit bf98cc25 (Genex: Evaluate TARGET_OBJECTS as a normal
expression., 2014-02-26).

Ensure that we don't attempt to evaluate the TARGET_OBJECTS generator
expression at configure-time, as can happen if CMP0024 or CMP0026
are OLD.  Use old-style parsing of the source item to extract
object target names in that case.

Avoid calling GetProperty("SOURCES") to bypass warnings from CMP0051.
Refactor existing logic in GetLanguages which is similar in intent to
the new GetSourceFiles code.
2014-04-13 10:59:50 +02:00
Stephen Kelly 9407174b1a target_sources: New command to add sources to target. 2014-04-02 23:14:02 +02:00
Stephen Kelly 81ad69e056 Make the SOURCES target property writable. 2014-04-02 23:14:02 +02:00
Stephen Kelly 6e636f2eba cmTarget: Make the SOURCES origin tracable. 2014-04-02 23:14:02 +02:00
Stephen Kelly e6971df6ab cmTarget: Make the source files depend on the config.
Disallow the use of config-specific source files with
the Visual Studio and Xcode generators. They don't have
any way to represent the condition currently.

Use the same common-config API in cmQtAutoGenerators. While
it accepts config-specific files, it doesn't have to support
multiple configurations yet.

Loop over the configs in cmTargetTraceDependencies
and cmGlobalGenerator::WriteSummary and consume all source
files.

Loop over the configs in cmComputeTargetDepends and compute the
object library dependencies for each config.
2014-04-02 23:14:02 +02:00