summaryrefslogtreecommitdiff
path: root/Tests/RunCMake/TargetSources
Commit message (Collapse)AuthorAgeFilesLines
* Testing: Update hard-coded line numbers to [0-9]+ in some testsKyle Edwards2018-10-102-6/+6
|
* target_sources: Interpret relative paths as relative to the calling directoryPatrick Stotko2018-06-1829-0/+161
| | | | | | | | | | Previously the command considered non-absolute source file paths relative to the associated target on the LHS. This causes problems in incremental builds where files are added from subdirectories and forces users to workaround by manually converting to absolute paths. Change this to enable more intuitive usage by projects. Fixes #17981
* VS,Xcode: Add CMakeLists.txt sources without mutating targetsBrad King2017-10-185-50/+1
| | | | | | | | | | | | Rather than injecting `CMakeLists.txt` files into each target's `SOURCES`, teach the generators to add them during generation using dedicated code. This avoids mutating the original targets, and avoids polluting `$<TARGET_PROPERTY:foo,SOURCES>` with generator-specific content. This also avoids listing the `CMakeLists.txt` sources in the results of `CMAKE_DEBUG_TARGET_PROPERTIES==SOURCES` so the `RunCMake.TargetSources` test no longer needs a separate case for IDEs.
* Merge topic 'deprecate-policy-old'Brad King2017-04-251-0/+10
|\ | | | | | | | | | | | | 4f5bbbea Add deprecation warnings for policies CMP0036 and below Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !743
| * Add deprecation warnings for policies CMP0036 and belowBrad King2017-04-211-0/+10
| | | | | | | | | | | | The OLD behaviors of all policies are deprecated, but only by documentation. Add an explicit deprecation diagnostic for some policies to encourage projects to port away from setting policies to OLD.
* | Xcode: Drop support for Xcode versions below 3Brad King2017-04-221-1/+1
|/
* Revise C++ coding style using clang-formatKitware Robot2016-05-164-4/+4
| | | | | | | | | | | | | 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.
* cmListFileBacktrace: Refactor storage to provide efficient value semanticsBrad King2016-04-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Allow export of targets with INTERFACE_SOURCES.Stephen Kelly2015-02-116-11/+1
| | | | | | Use the same rules for paths in source and binary dirs in installed INTERFACE_SOURCES as are used for INTERFACE_INCLUDE_DIRECTORIES.
* RunCMake: Remove unneeded files.Stephen Kelly2015-02-091-1/+0
| | | | | The default expectation of RunCMake tests is empty content, so there is no need to specify it.
* Export: Disallow export of targets with INTERFACE_SOURCESStephen Kelly2014-11-297-0/+17
| | | | | | | | | | | | | | | | | | | 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.
* cmTarget: Don't allow relative paths in INTERFACE_SOURCESStephen Kelly2014-11-296-1/+18
| | | | | | | | | | | | | | | | | | | 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.
* Tests: Fix RunCMake.TargetSources on Xcode 1.5Brad King2014-06-062-5/+4
| | | | | | 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.
* cmTarget: Fix listing of source files at configure-time.Stephen Kelly2014-04-135-1/+18
| | | | | | | | | | | | | | | | | | 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.
* target_sources: New command to add sources to target.Stephen Kelly2014-04-024-0/+26
|
* Make the SOURCES target property writable.Stephen Kelly2014-04-024-0/+28
|
* cmTarget: Make the SOURCES origin tracable.Stephen Kelly2014-04-027-0/+60
|
* cmTarget: Make the source files depend on the config.Stephen Kelly2014-04-027-0/+40
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.