summaryrefslogtreecommitdiffstats
path: root/Tests/ExportImport/Import/A
Commit message (Collapse)AuthorAgeFilesLines
* Allow OBJECT libraries to be installed, exported, and importedRobert Maynard2017-04-182-0/+18
| | | | | | | | Teach install() and export() to handle the actual object files. Disallow this on Xcode with multiple architectures because it still cannot be cleanly supported there. Co-Author: Brad King <brad.king@kitware.com>
* Tests: ExportImport C code should use explicit (void) in prototypesRobert Maynard2017-04-181-12/+12
|
* Revise C++ coding style using clang-formatKitware Robot2016-05-166-18/+15
| | | | | | | | | | | | | 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.
* Format include directive blocks and ordering with clang-formatBrad King2016-04-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sort include directives within each block (separated by a blank line) in lexicographic order (except to prioritize `sys/types.h` first). First run `clang-format` with the config file: --- SortIncludes: false ... Commit the result temporarily. Then run `clang-format` again with: --- SortIncludes: true IncludeCategories: - Regex: 'sys/types.h' Priority: -1 ... Commit the result temporarily. Start a new branch and cherry-pick the second commit. Manually resolve conflicts to preserve indentation of re-ordered includes. This cleans up the include ordering without changing any other style. Use the following command to run `clang-format`: $ git ls-files -z -- \ '*.c' '*.cc' '*.cpp' '*.cxx' '*.h' '*.hh' '*.hpp' '*.hxx' | egrep -z -v '(Lexer|Parser|ParserHelper)\.' | egrep -z -v '^Source/cm_sha2' | egrep -z -v '^Source/(kwsys|CursesDialog/form)/' | egrep -z -v '^Utilities/(KW|cm).*/' | egrep -z -v '^Tests/Module/GenerateExportHeader' | egrep -z -v '^Tests/RunCMake/CommandLine/cmake_depends/test_UTF-16LE.h' | xargs -0 clang-format -i This selects source files that do not come from a third-party. Inspired-by: Daniel Pfeifer <daniel@pfeifer-mail.de>
* Tests: Use a less strict regular expression to look for "SONAME"Raphael Kubo da Costa2015-09-012-2/+2
| | | | | | | | | | | | | | | | | | | Commit 899458ab (Tests: Cover NO_SONAME property for SHARED libraries, 2015-08-20) introduced a few new ExportImport tests, and the check_lib_{no}soname.cmake scripts that parse readelf(1)'s output. Make the regular expression matching the SONAME line output by readelf less strict, as the output format varies across implementations: GNU binutils' readelf is the only one to write each ELF header within parentheses (which the previous regular expression expected). The new tests were thus failing when either Fedora's elfutils (eu-readelf) or elftoolchain's readelf (present on recent FreeBSD versions) were being used, as they both list the headers without parentheses. The same issue also affected Tests/Plugin's check_mod_soname.cmake, so fix that one as well -- the only reason the test was not failing is that it tested that the regular expression did not match, which was always the case with a non-binutils readelf.
* Tests: Cover NO_SONAME property for SHARED librariesBrad King2015-08-203-0/+58
| | | | | | | | This property was added by commit v2.8.9~204^2~2 (Support building shared libraries or modules without soname, 2012-04-22). A test for using the property on MODULE libraries was added by commit v2.8.9~204^2~1 (Test NO_SONAME property, 2012-04-23). Add such a test for SHARED libraries too.
* Add generator expression support to OUTPUT_DIRECTORY target propertiesRobert Goulet2015-08-122-1/+14
| | | | | | | If {ARCHIVE,LIBRARY,RUNTIME}_OUTPUT_DIRECTORY is set with a genex then do not add the per-config subdirectory on multi-config generators. This will allow projects to use $<CONFIG> to place the per-config part of the directory path somewhere other than the end.
* Add generator expression support to OUTPUT_NAME target propertyRobert Goulet2015-07-092-1/+4
|
* Tests: Fix ExportImport on AIX with GCCBrad King2015-04-231-0/+1
| | | | | | | | | | | | | | | | | | | | | The iface_test_bld gets the excludedFromAll include directory with "-isystem" because it is added indirectly through an imported target. On AIX with GCC the -isystem flag causes sources to be preprocessed as: # 3 "/.../excludedFromAll.h" 2 3 4 The flags after the file name are documented here: https://gcc.gnu.org/onlinedocs/cpp/Preprocessor-Output.html and the "4" flag says that following content is extern "C". This causes the excludedFromAll function to be declared as a C symbol and not mangled for C++, which fails to link later because the symbol is really provided as C++. Work around this by setting the NO_SYSTEM_FROM_IMPORTED target property on iface_test_bld. Somehow iface_test_exp does not end up with -isystem so we do not need this workaround for that target.
* install: Allow generator expressions in TARGETS DESTINATION (#14317)Brad King2015-02-112-0/+4
| | | | | | | | | | | | This will allow per-config destinations for targets in EXPORT sets. Using multiple install(TARGETS) with separate CONFIGURATIONS is rejected as a target appearing more than once in an export set. Now instead one can write install(TARGETS foo EXPORT exp DESTINATION lib/$<CONFIG>) to get a single logical membership of the target in the export set while still having a per-config destination.
* try_run: Add tests for LINK_LIBRARIES with mock libraries.Matt McCormick2015-01-261-0/+30
| | | | | Extend the ExportImport test to try using an imported library with try_run.
* install: Allow absolute EXPORT destination with relative targets (#15258)Brad King2014-12-152-0/+25
| | | | | | | | | | | | | | | | | When install(EXPORT) is given an absolute destination we cannot compute the install prefix relative to the installed export file location. Previously we disallowed installation of targets in such exports with a relative destination, but did not enforce this for target property values besides the location of the main target file. This could lead to broken installations when the EXPORT is installed to an absolute path but usage requirements are specified relative to the install prefix. Since an EXPORT installed to an absolute destination cannot be relocated we can just hard-code the value of CMAKE_INSTALL_PREFIX as the base for relative paths. This will allow absolute install(EXPORT) destinations to work with relative destinations for targets and usage requirements. Extend the ExportImport test with a case covering this behavior.
* install: Support generator expressions in FILES and PROGRAMS modeBrad King2014-02-212-0/+17
| | | | | | | | Teach the install(FILES) and install(PROGRAMS) commands to evaluate generator expressions in the list of files. Extend the ExportImport test to cover installation cases involving generator expressions.
* Export: Prefix relative items with genexes in INSTALL_INTERFACE.Stephen Kelly2013-11-261-0/+1
| | | | | | | | | | | | | | Code such as target_include_directories(foo INTERFACE $<INSTALL_INTERFACE:include$<FOO>> ) should be treated as a relative directory, despite the genex, after the INSTALL_INTERFACE is stripped away. Previously, this would generate a relative directory on export, which would be an error on import, so no policy is needed.
* Export: Process INSTALL_INTERFACE in INCLUDES DESTINATION.Stephen Kelly2013-11-261-0/+3
| | | | | | | | | | Code such as install(TARGETS ... INCLUDES DESTINATION $<INSTALL_INTERFACE:include> ) should behave as if the INSTALL_INTERFACE wrapper were not present.
* Export: Process relative includes after genex evaluation.Stephen Kelly2013-11-261-0/+2
| | | | | | | | | | | | | In code such as install(TARGETS ... INCLUDES DESTINATION $<FOO>include ) the generator expressions are evaluated at generate-time. Delay determining whether each entry is a relative path until after the generator expressions are evaluated. Such relative paths are based relative to the CMAKE_INSTALL_PREFIX.
* Always consider includes from IMPORTED targets to be SYSTEM.Stephen Kelly2013-09-242-0/+56
| | | | | | | Introduce a target property to control this behavior variable to set the default value for the target property. This does not affect try_compile runs.
* Merge topic 'install-interface-relative'Brad King2013-07-261-0/+1
|\ | | | | | | | | d777b8e Genex: Allow relative paths in INSTALL_INTERFACE.
| * Genex: Allow relative paths in INSTALL_INTERFACE.Stephen Kelly2013-07-251-0/+1
| | | | | | | | | | | | | | These paths can be prepended with the ${_IMPORT_PREFIX} generated in the export file. Such relative paths were previously an error.
* | Merge topic 'install-interface-includes'Brad King2013-07-261-0/+3
|\ \ | |/ | | | | | | 650e61f Add a convenient way to add the includes install dir to the INTERFACE.
| * Add a convenient way to add the includes install dir to the INTERFACE.Stephen Kelly2013-07-241-0/+3
| | | | | | | | | | | | | | Export the INCLUDES DESTINATION without appending to the INTERFACE_INCLUDE_DIRECTORIES of the target itself. That way, a target can be exported multiple times with different INCLUDES DESTINATION without unintended cross-pollution of export sets.
* | Use linked frameworks as a source of include directories.Stephen Kelly2013-07-243-0/+19
|/
* Merge topic 'INTERFACE_LINK_LIBRARIES-prop'Brad King2013-07-157-0/+38
|\ | | | | | | | | | | | | | | | | 3e30d9e TLL: Don't populate old link interface if CMP0022 is NEW. 574fec9 Export: Generate INTERFACE_LINK_LIBRARIES property on targets. d0a76ea Introduce the INTERFACE_LINK_LIBRARIES property. ddde61c Introduce the LINK_ONLY generator expression. 5aa9731 GenexEval: Add abstracted access to link interface for a target.
| * Export: Generate INTERFACE_LINK_LIBRARIES property on targets.Stephen Kelly2013-07-087-0/+38
| | | | | | | | | | | | | | | | | | | | This property is generated only for targets which have recorded policy CMP0022 as NEW, and a compatibility mode is added to additionally export the old interfaces in that case too. If the old interfaces are not exported, the generated export files require CMake 2.8.12. Because the unit tests use a version which is not yet called 2.8.12, temporarily require a lower version.
* | Merge topic 'IMPORTED-build-dependencies'Brad King2013-07-155-0/+62
|\ \ | |/ |/| | | | | | | 4f7ceb5 Test non-IMPORTED libraries in the INTERFACE of IMPORTED libraries. 3405351 Add entire link interface transitive closure as target depends.
| * Test non-IMPORTED libraries in the INTERFACE of IMPORTED libraries.Stephen Kelly2013-07-025-0/+62
| | | | | | | | | | | | | | | | | | | | If a non-IMPORTED library is added to the INTERFACE_LINK_LIBRARIES of a IMPORTED target, the non-IMPORTED target needs to become a target dependency and link dependency of the consuming target. This is already the case since commit 30962029 (Make targets depend on the link interface of their dependees, 2012-12-26), and fixed in the parent commit, so test that it works.
* | Generate INTERFACE_COMPILE_OPTIONS on export.Stephen Kelly2013-06-102-0/+19
|/ | | | | This was missing from commit 80ca9c4b (Add COMPILE_OPTIONS target property., 2013-05-16).
* Add EXPORT_NAME property.Stephen Kelly2013-05-183-1/+17
| | | | | | This allows for example, the buildsystem to use names like 'boost_any' instead of the overly generic 'any', and still be able to generate IMPORTED targets called 'boost::any'.
* Add includes and compile definitions with target_link_libraries.Stephen Kelly2013-01-311-13/+1
| | | | | | | | This establishes that linking is used to propagate usage-requirements between targets in CMake code. The use of the target_link_libraries command as the API for this is chosen because introducing a new command would introduce confusion due to multiple commands which differ only in a subtle way.
* Export targets to a targets file, not a Config file.Stephen Kelly2013-01-311-2/+2
|
* Don't allow targets args in the new target commands.Stephen Kelly2013-01-291-6/+13
|
* Add the COMPATIBLE_INTERFACE_STRING property.Stephen Kelly2013-01-242-0/+6
|
* Export the COMPATIBLE_INTERFACE_BOOL content propertiesStephen Kelly2013-01-212-0/+6
|
* Make INTERFACE determined properties readable in generator expressions.Stephen Kelly2013-01-202-1/+10
| | | | | The properties are evaluated as link-dependent interface properties when evaluating the generator expressions.
* Export the INTERFACE_PIC property.Stephen Kelly2013-01-152-0/+24
|
* Make the BUILD_INTERFACE of export()ed targets work.Stephen Kelly2013-01-152-4/+18
| | | | | The existing BUILD_INTERFACE code is executed at generate time, which is too late for export().
* Add a test for the interfaces in targets exported from the build tree.Stephen Kelly2013-01-151-16/+13
|
* Allow generator expressions in LINK_INTERFACE_LIBRARIES.Stephen Kelly2013-01-102-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Config and IMPORTED_ variants may also contain generator expressions. If 'the implementation is the interface', then the result of evaluating the expressions at generate time is used to populate the IMPORTED_LINK_INTERFACE_LIBRARIES property. 1) In the case of non-static libraries, this is fine because the user still has the option to populate the LINK_INTERFACE_LIBRARIES with generator expressions if that is what is wanted. 2) In the case of static libraries, this prevents a footgun, enforcing that the interface and the implementation are really the same. Otherwise, the LINK_LIBRARIES could contain a generator expression which is evaluated with a different context at build time, and when used as an imported target. That would mean that the result of evaluating the INTERFACE_LINK_LIBRARIES property for a static library would not necessarily be the 'link implementation'. For example: add_library(libone STATIC libone.cpp) add_library(libtwo STATIC libtwo.cpp) add_library(libthree STATIC libthree.cpp) target_link_libraries(libtwo $<$<STREQUAL:$<TARGET_PROPERTY:TYPE>,STATIC_LIBRARY>:libone>) target_link_libraries(libthree libtwo) If the LINK_LIBRARIES content was simply copied to the IMPORTED_LINK_INTERFACE_LIBRARIES, then libthree links to libone, but executables linking to libthree will not link to libone. 3) As the 'implementation is the interface' concept is to be deprecated in the future anyway, this should be fine.
* Fix linking to imported libraries test.Stephen Kelly2013-01-102-3/+3
| | | | | | | Make a C executable instead of attempting to make a C++ static library (and not really succeeding). This was introduced in commit 894f52f3 (Handle INTERFACE properties transitively for includes and defines., 2012-09-23).
* Handle INTERFACE properties transitively for includes and defines.Stephen Kelly2013-01-052-0/+39
| | | | | Contextually, the behavior is as if the properties content from another target is included in the string and then the result is evaluated.
* exports: add a test for exporting dependent targetsAlex Neundorf2012-09-301-0/+4
| | | | | | | The test exports two libraries into two separate exports, and then include()s the generated export files. This must not fail. Alex
* Remove CMake-language block-end command argumentsKitware Robot2012-08-131-1/+1
| | | | | | | | | | | | | | | | | Ancient versions of CMake required else(), endif(), and similar block termination commands to have arguments matching the command starting the block. This is no longer the preferred style. Run the following shell code: for c in else endif endforeach endfunction endmacro endwhile; do echo 's/\b'"$c"'\(\s*\)(.\+)/'"$c"'\1()/' done >convert.sed && git ls-files -z -- bootstrap '*.cmake' '*.cmake.in' '*CMakeLists.txt' | egrep -z -v '^(Utilities/cm|Source/kwsys/)' | egrep -z -v 'Tests/CMakeTests/While-Endwhile-' | xargs -0 sed -i -f convert.sed && rm convert.sed
* Check*.cmake: Expand imported targets in CMAKE_REQUIRED_LIBRARIESAlex Neundorf2012-02-211-0/+11
| | | | | | | | | | | Add the function cmake_expand_imported_targets() to expand imported targets in a list of libraries into their on-disk file names for a particular configuration. Adapt the implementation from KDE's HANDLE_IMPORTED_TARGETS_IN_CMAKE_REQUIRED_LIBRARIES which has been in use for over 2 years. Call the function from all the Check*.cmake macros to handle imported targets named in CMAKE_REQUIRED_LIBRARIES. Alex
* Honor custom command dependencies on imported targets (#10395)Brad King2010-12-081-5/+45
| | | | | | | Imported targets do not themselves build, but we can follow dependencies through them to find real targets. This allows imported targets to depend on custom targets that provide the underlying files at build time.
* Allow add_dependencies() on imported targets (#10395)Brad King2010-11-192-1/+17
| | | | | | | Imported targets do not themselves build, but we can follow dependencies through them to find real targets. This allows imported targets to depend on custom targets that provide the underlying files at build time.
* Test link multiplicity export/importBrad King2009-09-012-1/+4
| | | | | | | We test that LINK_INTERFACE_MULTIPLICITY propagates through export() and install(EXPORT) into dependent projects. A simple cycle of two archives that need to be scanned three times ensures that the importing project uses the multiplicity correctly.
* ENH: Test export/import of link interface languagesBrad King2009-07-112-1/+4
| | | | | | | This extends the ExportImport test. The Export project creates a C++ static library and exports it. Then the Import project links the library into a C executable. On most platforms the executable will link only if the C++ linker is chosen correctly.
* ENH: Allow IMPORTED_IMPLIB w/o IMPORTED_LOCATIONBrad King2009-04-082-2/+14
| | | | | | Linking to a Windows shared library (.dll) requires only its import library (.lib). This teaches CMake to recognize SHARED IMPORTED library targets that set only IMPORTED_IMPLIB and not IMPORTED_LOCATION.
* ENH: Test transitive link to subdir-imported libBrad King2009-04-064-0/+109
This tests linking to an imported target that is not visible but is a transitive dependency of a target that is visible. See issue #8843.
generated by cgit v0.12 at 2025-03-19 18:03:04 (GMT)