- 26 Apr, 2016 1 commit
-
-
Kitware Robot authored
-
- 25 Apr, 2016 1 commit
-
-
Kitware Robot authored
-
- 24 Apr, 2016 1 commit
-
-
Kitware Robot authored
-
- 23 Apr, 2016 1 commit
-
-
Kitware Robot authored
-
- 22 Apr, 2016 6 commits
-
-
A qrc_NAME.cpp file generated from NAME.qrc in the directory CMAKE_CURRENT_SOURCE_DIR/SUBDIR will be generated in the directory CMAKE_CURRENT_BINARY_DIR/TARGETNAME_automoc.dir/SUBDIR
-
Not included moc files generated from a source file in CMAKE_CURRENT_SOURCE_DIR/SUBDIR will be generated in the directory CMAKE_CURRENT_BINARY_DIR/TARGETNAME_automoc.dir/SUBDIR/
-
-
-
The test exits with an error if two or more source files would generate the same moc file.
-
Kitware Robot authored
-
- 21 Apr, 2016 1 commit
-
-
Kitware Robot authored
-
- 20 Apr, 2016 6 commits
-
-
Rolf Eike Beer authored
This takes a std::string&, so directly pass the object to it instead of converting back and forth.
-
Rolf Eike Beer authored
All callers already have one, and it was immediately converted to one internally. Just keep the old one around, and only modify it when needed.
-
Rolf Eike Beer authored
All callers already have these objects, and it is only passed to other methods taking such, so avoid all conversions in between.
-
Rolf Eike Beer authored
This function already takes a const std::string&, no need to convert the input to a char* before passing it in.
-
Rolf Eike Beer authored
Running the testsuite this function is entered more than 126,000 times. Reorder the code flow so that a conversion from char* to std::string is only done when the cache entry is a path one, which happens only ~50 times during the testsuite.
-
Kitware Robot authored
-
- 19 Apr, 2016 9 commits
-
-
-
The single map allows name collision testing (in a later commit)
-
-
-
-
-
While at it, simplify the signature and avoid a trailing separator.
-
-
Kitware Robot authored
-
- 18 Apr, 2016 4 commits
-
-
Brad King authored
All callers now pass a full backtrace so we do not need the alternative that takes a cmListFileContext directly. Drop this overload to remove the code duplication.
-
Brad King authored
This information is now kept in cmMakefile::Backtrace.
-
Brad King authored
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.
-
Kitware Robot authored
-
- 17 Apr, 2016 1 commit
-
-
Kitware Robot authored
-
- 16 Apr, 2016 1 commit
-
-
Kitware Robot authored
-
- 15 Apr, 2016 8 commits
-
-
Brad King authored
-
-
Brad King authored
Ensure the destination directory exists before creating symlinks in it.
-
Brad King authored
Changes during post-3.3/pre-3.4 development refactored storage of most configure-time information, including variable bindings and function scopes. All scopes (even short-lived) were kept persistently for possible future debugging features, causing huge accumulated memory usage. This was mostly addressed by commit v3.4.1~4^2 (cmState: Avoid accumulating snapshot storage for short-lived scopes, 2015-11-24). Since then we still keep short-lived scopes when they are needed for a backtrace. This is because since commit v3.4.0-rc1~378^2 (cmListFileBacktrace: Implement in terms of cmState::Snapshot, 2015-05-29) backtraces have been lightweight objects that simply point into the snapshot tree. While the intention of this approach was to avoid duplicating the call stack file path strings, the cost turned out to be holding on to the entire call stack worth of scope snapshots, which is much worse. Furthermore, since commit v3.4.0-rc2~1^2 (cmIfCommand: Issue CMP0054 warning with appropriate context, 2015-10-20) all conditions used in `if()` commands hold a backtrace for use in diagnostic messages. Even though the backtrace is short-lived it still causes the scope snapshot to be kept. This means that code like function(foo) if(0) endif() endfunction() foreach(i RANGE 1000000) foo() endforeach() accumulates storage for the function call scope snapshots. Fix this by partially reverting commit v3.4.0-rc1~378^2 and saving the entire call stack during cmListFileBacktrace construction. This way we can avoid keeping short-lived scope snapshot storage in all cases.
-
Brad King authored
The bottom of the call stack is always a long-lived snapshot and can be saved for later use with cmOutputConverter.
-
Brad King authored
In commit v2.8.4~32^2~14 (Use cmake::IssueMessage for warnings, 2010-12-07) these warnings became formatted. It is more informative to give the full call stack with such warnings. Also it is easier to implement warnings with a full call stack because we do not have to construct a custom backtrace with only the top.
-
Brad King authored
This method was added by commit v3.4.0-rc1~424^2~6 (cmLocalGenerator: Add IssueMessage method, 2015-06-13) in order to reduce callers' dependency on cmMakefile. Currently the implementation of cmLocalGenerator::IssueMessage is just a copy of the post-configure code path in cmMakefile::IssueMessage. De-duplicate the implementation by simply calling the cmMakefile copy for now. This will simplify upcoming refactoring of backtraces. The dependency on cmMakefile can be removed by future work once that is done.
-
Brad King authored
-