summaryrefslogtreecommitdiffstats
path: root/Tests/ExportImport/Export
Commit message (Collapse)AuthorAgeFilesLines
...
* | Generate INTERFACE_COMPILE_OPTIONS on export.Stephen Kelly2013-06-101-1/+5
|/ | | | | This was missing from commit 80ca9c4b (Add COMPILE_OPTIONS target property., 2013-05-16).
* Add EXPORT_NAME property.Stephen Kelly2013-05-186-6/+48
| | | | | | 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'.
* install(EXPORT): Ensure clean INTERFACE_INCLUDE_DIRECTORIESStephen Kelly2013-03-261-2/+16
| | | | | | | | | | Check that source and binary directories are not part of the INTERFACE_INCLUDE_DIRECTORIES for installed IMPORTED targets. This is limited to directories which do not contain generator expressions to evaluate. Such paths can only be checked at time of use of the imported target, which will be done in a follow up patch.
* Rename variable for including current directory in interfacesBrad King2013-03-192-2/+2
| | | | | | | | | Rename the variable added by commit 9ce1b9ef (Add CMAKE_BUILD_INTERFACE_INCLUDES build-variable, 2012-11-25) to CMAKE_INCLUDE_CURRENT_DIR_IN_INTERFACE to be more consistent with the existing CMAKE_INCLUDE_CURRENT_DIR variable. Suggested-by: Alex Neundorf <neundorf@kde.org>
* Fix cmGeneratorExpression::Preprocess for interleaved inputs.Stephen Kelly2013-03-181-0/+4
| | | | | | | | | | | | | | We can't find both preprocessing expressions at once, because then the BUILD_INTERFACE will always be favored if both are present, even if INSTALL_INTERFACE appears first. This was affecting the behavior of install(EXPORT) because the INTERFACE_INCLUDE_DIRECTORIES contained entries like /foo/include;$<INSTALL_INTERFACE:/bar/include> As the INSTALL_INTERFACE always evaluates to '0', it always needs to be preprocessed properly.
* Remove use of TARGET_DEFINED from the ExportImport test.Stephen Kelly2013-02-251-1/+1
| | | | | | Update the unit test introduced in commit 5daaa5c4 (Fix TARGET_PROPERTY target extractions., 2013-01-26) to not use the expression, but still test the appropriate code.
* Add includes and compile definitions with target_link_libraries.Stephen Kelly2013-01-311-17/+20
| | | | | | | | 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
|
* Merge topic 'fix-TARGET_PROPERTY-extraction'Brad King2013-01-291-0/+2
|\ | | | | | | | | 5daaa5c Fix TARGET_PROPERTY target extractions.
| * Fix TARGET_PROPERTY target extractions.Stephen Kelly2013-01-291-0/+2
| | | | | | | | | | | | | | We need to make sure we can export targets which have content such as $<0:$<TARGET_PROPERTY:not_a_target,INTERFACE_INCLUDE_DIRECTORIES> That means making not finding a target non-fatal here.
* | Add the INSTALL_PREFIX genex.Stephen Kelly2013-01-271-1/+16
|/
* Add the COMPATIBLE_INTERFACE_STRING property.Stephen Kelly2013-01-241-1/+8
|
* Export the COMPATIBLE_INTERFACE_BOOL content propertiesStephen Kelly2013-01-211-0/+9
|
* Test evaluation target via export for generator expressionsStephen Kelly2013-01-151-1/+1
|
* Export the INTERFACE_PIC property.Stephen Kelly2013-01-151-0/+4
|
* Make the BUILD_INTERFACE of export()ed targets work.Stephen Kelly2013-01-154-1/+28
| | | | | 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-0/+1
|
* Allow generator expressions in LINK_INTERFACE_LIBRARIES.Stephen Kelly2013-01-105-1/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Handle INTERFACE properties transitively for includes and defines.Stephen Kelly2013-01-052-1/+90
| | | | | 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-303-0/+17
| | | | | | | 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-2/+2
| | | | | | | | | | | | | | | | | 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
* Follow all dependencies of shared library private dependenciesBrad King2011-12-143-2/+25
| | | | | | | | | In cmComputeLinkDepends we compute the transitive closure of private shared library dependencies. When a shared library is added to this closure we must follow all of its dependencies whether they are private or public. Previously we only followed the private dependencies. Fix the implementation to follow the public dependencies too. Also extend the ExportImport test to cover this case.
* Test link multiplicity export/importBrad King2009-09-017-0/+22
| | | | | | | 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.
* COMP: Fix ExportImport testLib6 on VS6Brad King2009-07-132-1/+1
| | | | | The compiler does not support multiple source files differing only by extension in one target. This renames the C source file in the test.
* ENH: Test export/import of link interface languagesBrad King2009-07-113-3/+17
| | | | | | | 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: Remove CMAKE_ANSI_CFLAGS from testsBrad King2009-07-081-5/+0
| | | | | As of CMake 2.6 this variable is not defined, and the ANSI flags for the HP compiler are simply hard-coded in the default C flags.
* ENH: Allow more specification of target file namesBrad King2009-05-011-0/+9
| | | | | | | | | | | | | | This creates target properties ARCHIVE_OUTPUT_NAME, LIBRARY_OUTPUT_NAME, and RUNTIME_OUTPUT_NAME, and per-configuration equivalent properties ARCHIVE_OUTPUT_NAME_<CONFIG>, LIBRARY_OUTPUT_NAME_<CONFIG>, and RUNTIME_OUTPUT_NAME_<CONFIG>. They allow specification of target output file names on a per-type, per-configuration basis. For example, a .dll and its .lib import library may have different base names. For consistency and to avoid ambiguity, the old <CONFIG>_OUTPUT_NAME property is now also available as OUTPUT_NAME_<CONFIG>. See issue #8920.
* ENH: Allow IMPORTED_IMPLIB w/o IMPORTED_LOCATIONBrad King2009-04-082-1/+22
| | | | | | 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: Allow a custom list of debug configurationsBrad King2008-09-041-0/+4
| | | | | | Create a DEBUG_CONFIGURATIONS global property as a way for projects to specify which configuration names are considered to be 'debug' configurations.
* ENH: Make link interface mode more distinctBrad King2008-08-181-1/+2
| | | | | | | | | Rename the recently added INTERFACE mode of the target_link_libraries() command to LINK_INTERFACE_LIBRARIES. This makes it much more distinct from a normal call to the command, and clearly states its connection to the property of the same name. Also require the option to appear immediately after the target name to make it a mode rather than an option.
* BUG: Fix ExportImport test on VS6Brad King2008-08-123-2/+10
| | | | | Visual Studio 6 does not support per-target object files, so just use two separate source file names in this case.
* ENH: Test target_link_libraries INTERFACE optionBrad King2008-08-114-1/+50
|
* ENH: preclean some warningsKen Martin2008-03-251-0/+1
|
* ENH: Improve exporting/importing of targetsBrad King2008-02-061-1/+4
| | | | | - Use real name instead of link for location of versioned targets - Error when a target is exported multiple times
* COMP: Convert C function prototypes to use (void) instead of ().Brad King2008-02-034-5/+5
|
* BUG: Remove InstallNameFixupPath from cmTarget and cmInstallTargetGenerator.Brad King2008-02-011-8/+8
| | | | | | | | | - Motivation: - It depended on the order of installation - It supported only a single destination for each target - It created directory portions of an install name without user request - Updated ExportImport test to install targets in an order that expoed this bug
* ENH: Update ExportImport test to enforce dependent library pathsBrad King2008-02-011-0/+9
| | | | | - Build without rpaths - Place implementation libs in separate directories
* ENH: Support linking to shared libs with dependent libsBrad King2008-01-311-10/+5
| | | | | | | | | - Split IMPORTED_LINK_LIBRARIES into two parts: IMPORTED_LINK_INTERFACE_LIBRARIES IMPORTED_LINK_DEPENDENT_LIBRARIES - Add CMAKE_DEPENDENT_SHARED_LIBRARY_MODE to select behavior - Set mode to LINK for Darwin (fixes universal binary problem) - Update ExportImport test to account for changes
* ENH: Updated ExportImport test to try LINK_INTERFACE_LIBRARIES.Brad King2008-01-305-3/+47
|
* ENH: Support exporting/importing of AppBundle targets.Brad King2008-01-282-2/+30
| | | | | | | | - Imported bundles have the MACOSX_BUNDLE property set - Added cmTarget::IsAppBundleOnApple method to simplify checks - Document BUNDLE keyword in INSTALL command - Updated IMPORTED_LOCATION property documentation for bundles - Updated ExportImport test to test bundles
* BUG: Fix export/import file generation to not store link dependencies of ↵Brad King2008-01-283-1/+6
| | | | executables or modules.
* ENH: Restored APPEND option to EXPORT() command in new implementation.Brad King2008-01-281-1/+5
|
* ENH: Added framework to ExportImport test.Brad King2008-01-282-2/+13
|
* ENH: Added ExportImport test to test new export/import features.Brad King2008-01-286-0/+81
generated by cgit v0.12 at 2025-03-23 08:05:08 (GMT)