[cmake-developers] problem with export(TARGETS ...)

[Brad King]

On 01/27/2011 05:55 PM, Clinton Stimpson wrote:
> On Thursday, January 27, 2011 03:23:44 pm Brad King wrote:
>> Moving forward, we could consider adding a new property for IMPORTED
>> targets to mark them as "private".  This would tell CMake that it
>> is imported only for purposes like the above and should not be
>> referenced directly by the importing project.

Moving to developer's list.

> Thanks, that explains it.  But I did have one issue about the 
> usability/complexity of this export stuff.  These "private" libraries include 
> some 3rd party libraries.  I'd like to avoid modifying other people's 
> CMakeLists.txt files to put "EXPORT MyExportGroup" into install(TARGET ...) 
> commands, to be able to export my libraries.

CMake doesn't know/care whether certain directories in your project came
from third-party sources.  It's just evaluating the dependencies as it
sees them in your source.  By bringing the third-party libraries into
your project you are giving CMake the responsibility to make sure things
work.  The reason this isn't required for outside dependencies is that
CMake assumes the system (e.g. package manager) has take responsibility
for ensuring dependencies are available.

Things like this are part of the cost of trying to solve dependency
management problems with version control and build systems instead of
package managers.  We typically contribute a form like this back to the
third party library:

if(NOT MYLIB_INSTALL_EXPORT_NAME)
  set(MYLIB_INSTALL_EXPORT_NAME "mylib-targets")
  set(MYLIB_INSTALL_STANDALONE 1)
endif()
...
install(TARGET mylib EXPORT ${MYLIB_INSTALL_EXPORT_NAME})
...
if(MYLIB_INSTALL_STANDALONE)
  install(EXPORT ${MYLIB_INSTALL_EXPORT_NAME} DESTINATION lib/cmake/mylib-${v})
endif()

> What's the reason for that being required?

It's an implementation necessity to get correct/working builds.  When I first
designed it there was no IMPORTED_LINK_DEPENDENT_LIBRARIES and we ran into
real build problems that motivated its creation.

> From my point of view, it seems it would be cleaner and simpler it weren't 
> required.  What I see is cmake complaining about it not being in the export 
> group, when it could probably include it for me.  Perhaps the auto included 
> ones could be marked as private?

We might be able to do that for the export() command because CMake knows
where to locate all the targets in the build tree.  It won't work for the
install(EXPORT) command though because only the install(TARGET ... EXPORT)
commands know where the binaries will go, and without the EXPORT part of the
latter then CMake does not know which install rules are part of the export.
One target can be installed in multiple places by multiple install(TARGET)
commands.  Two separate groups of install rules can generate two independent
exports.

In order to avoid workarounds like the above MYLIB_INSTALL_EXPORT_NAME
I've thought about introducing export dependencies.  The third party
library would still need EXPORT rules but would not need to configure
them to match the outer project's name.  Instead the outer project's
export would specify that it depends on the inner project's export and
that would be enough to satisfy being "part of the export set".  However
I've not spent a great deal of time thinking about how to define this
dependency or what other implications it might have (e.g. export files
needing to know where their dependencies' export files are installed).

-Brad