Notes
(0025704) Brad King (manager) 2011-03-09 09:11	For SHARED libraries they LINK_INTERFACE_LIBRARIES property can be used to hide its dependencies from the public interface. The link interface of a MODULE library is empty because it is not available for linking (only dynamic loading). The code that generates this error message should take that into account. However, why bother listing a MODULE library in an export set? Nothing can link to it anyway.

(0025705) david.ingamells (reporter) 2011-03-09 09:15	Why bother? Because modules can be used as plugins see e.g. http://www.linuxjournal.com/article/3687 [^]

(0025706) Brad King (manager) 2011-03-09 09:20	Sure, that is a great reason to build and INSTALL a MODULE target but not a reason to EXPORT the target from the install tree. The purpose of an EXPORT set is to make it easy for outside applications to _link_ to your libraries: http://www.cmake.org/Wiki/CMake/Tutorials/Exporting_and_Importing_Targets [^] Just leave off the "EXPORT mapapi_core" line from the MODULE's INSTALL() rule and the error will go away with no ill effects.

(0025707) david.ingamells (reporter) 2011-03-09 09:30	WRONG!!!!!~! Lots of ill effects. For every build/EXPORT _another_ project will want to do a build/IMPORT. Sure it will go away from the build, but I use a small amount of cmake script in several client projects that pulls in the exported module from the plugin project, and _that_ build will fail if it can't import from the export. I would suggest that you don't judge others' needs by your own personal experiences. They will think of dozens of justified ways to use something that you have never thought of!

(0025708) Brad King (manager) 2011-03-09 09:36	What does the CMake code in the application that imports this module look like?

(0025709) david.ingamells (reporter) 2011-03-09 09:40	something like this ... GET_FILENAME_COMPONENT(DR_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH) INCLUDE(${DR_IMPORT_PREFIX}/mapapi_core.cmake) # copy all the exported targets from the installation to the client project. IF (INSTALLME_DESTINATION) SET(_TO_PATH ${INSTALLME_DESTINATION}) ELSE (INSTALLME_DESTINATION) SET(_TO_PATH ${CMAKE_INSTALL_PREFIX}/plugins) ENDIF (INSTALLME_DESTINATION) FOREACH (IMP mapapi_core_GenNav <etc>) GET_TARGET_PROPERTY (_FROM ${IMP} IMPORTED_LOCATION_RELEASE) GET_FILENAME_COMPONENT(_NAME ${_FROM} NAME) SET(_TO ${_TO_PATH}/${_NAME}) MESSAGE( STATUS "Copy File " ${_FROM} " to " ${_TO}) ADD_CUSTOM_TARGET(CP_${IMP} ALL COMMAND cp ${_FROM} ${_TO} DEPENDS ${CMAKE_INSTALL_PREFIX}) ENDFOREACH(IMP)

(0025710) Brad King (manager) 2011-03-09 11:40	As mentioned in 0011945:0025704 the link interface of MODULE libraries should be empty: http://cmake.org/gitweb?p=cmake.git;a=commitdiff;h=c6a8e4c7 [^] That should address this error and is internally cleaner anyway. > just plain dumb ... WRONG!!!!!~! ... Please use a more civil tone in the future. You're asking for free help from volunteers. > don't judge others' needs by your own personal experience Sorry, but from the amount of information originally presented it was not clear to me that you understood how to use EXPORTs. I thought you had simply cut-and-paste some install example from somewhere which had that line. In that case my suggestion was correct. Even though this was not the case I don't see how it was hurtful or judgemental to make the suggestion. > GET_TARGET_PROPERTY (_FROM ${IMP} IMPORTED_LOCATION_RELEASE) Side note: consider using the LOCATION or LOCATION_<CONFIG> (perhaps with <CONFIG>==RELEASE) instead: http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:LOCATION [^] http://www.cmake.org/cmake/help/cmake-2-8-docs.html#prop_tgt:LOCATION_CONFIG [^] IIRC it will work even when the IMPORTED_LOCATION_RELEASE property is not set because it is computed from the available imported configurations.

(0025726) david.ingamells (reporter) 2011-03-10 01:34	> You're asking for free help from volunteers. No, I wasn't asking for help. I was myself voluntarily providing the results of my several hours of testing to help improve the product. Please remember in future that people who take the time to investigate and report bugs are also free contributors. Please also draw the attention of the implementer of that buggy check to the fact that the world is wider than his experience, and that his changes can negatively affect the work of volunteers working on other _free_ projects that use cmake. Anyway congratulations on implementing a fix so quickly. This suggests that the internals of cmake are very clean and/or (more likely) that you have a very good understanding of those internals.

Issue History
Date Modified	Username	Field	Change
2011-03-09 08:59	david.ingamells	New Issue
2011-03-09 09:07	Brad King	Assigned To	=> Brad King
2011-03-09 09:07	Brad King	Status	new => assigned
2011-03-09 09:11	Brad King	Note Added: 0025704
2011-03-09 09:15	david.ingamells	Note Added: 0025705
2011-03-09 09:20	Brad King	Note Added: 0025706
2011-03-09 09:30	david.ingamells	Note Added: 0025707
2011-03-09 09:36	Brad King	Note Added: 0025708
2011-03-09 09:40	david.ingamells	Note Added: 0025709
2011-03-09 11:40	Brad King	Note Added: 0025710
2011-03-10 01:34	david.ingamells	Note Added: 0025726
2011-03-10 07:15	Brad King	Status	assigned => closed
2011-03-10 07:15	Brad King	Resolution	open => fixed
2011-06-17 18:36	David Cole	Fixed in Version	=> CMake 2.8.5
2011-06-17 18:36	David Cole	Target Version	=> CMake 2.8.5

Relationships