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

[Clinton Stimpson]

On Friday, January 28, 2011 06:14:41 am Brad King wrote:
> 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

I'm doing that MYLIB_INSTALL_EXPORT_NAME workaround for now anyway.
This export dependencies sounds nice.
I'm curious, would that also have to work with export files that are already 
installed on the system, not just ones that will be installed as part of a 
project?  Or would this be limited to the current build tree?

-- 
Clinton Stimpson
Elemental Technologies, Inc
Computational Simulation Software, LLC
www.csimsoft.com