[cmake-developers] Fwd: EXPORT_NAME-genex

Alexander Neundorf neundorf at kde.org
Sat May 25 15:22:39 EDT 2013


On Saturday 25 May 2013, Daniel Pfeifer wrote:
> 2013/5/22 Alexander Neundorf <neundorf at kde.org>
> 
> > On Monday 20 May 2013, Daniel Pfeifer wrote:
> > > 2013/5/20 Brad King <brad.king at kitware.com>
> > > 
> > > > We had some recent discussion about encouraging the convention of
> > > > "namespace::" for imported targets, but perhaps we should reconsider
> > > > the value and cost.
> > > 
> > > One of CMake's most powerful features in my opionion is the way it
> > 
> > handles
> > 
> > > sub-projects.
> > > I can take two CMake-projects, Foo and Bar, put them in my Worspace
> > > directory where I have a CMakeLists.txt file with the content:
> > > 
> > > add_subdirectory(Foo)
> > > add_subdirectory(Bar)
> > > 
> > > I can now build these two projects with the same tools and flags, which
> > 
> > is
> > 
> > > extremely handy for crosscompilation.
> > > This works pretty well in many cases, but sometimes it breaks, because
> > 
> > some
> > 
> > > projects are not "good neighbors" or they want to be the top level
> > 
> > project.
> > 
> > For instance target names must (should) be unique, and using
> > CMAKE_(SOURCE| BINARY)_DIR is usually a bad idea in this case.
> > 
> > > I would like to see more projects that can be built both on their own
> > > and as part of a bigger workspace.
> > > In this case, it is important that these projects make no distincion
> > > whether their dependencies are part of the same workspace or not.
> > 
> > I think they have to.
> > Let's say Bar depends on the library Foo, Bar has to search for it, and
> > fail
> > if it is not present:
> > 
> > Bar/CMakeLists.txt:
> > 
> > 
> > if(NOT TARGET Foo)
> > 
> >   find_package(Foo REQUIRED)
> > 
> > else()
> > 
> >   set(Foo_LIBRARIES Foo)
> >   set(Foo_INCLUDE_DIRS ${CMAKE_CURRENT_SOURCE_DIR}/somewhere )
> > 
> > endif()
> > ...
> > 
> > target_link_libraries(Bar ${Foo_LIBRARIES})
> > 
> > 
> > How would you handle it otherwise ?
> 
> Bar/CMakeLists.txt making use of usage requirements:
> 
> find_package(Foo REQUIRED)
> target_link_libraries(Bar Foo)
> 
> The (generated) top-level CMakeLists.txt file looks like:
> 
> project(Workspace NONE)
> set(PROJECTS_IN_WORKSPACE Foo Bar)
> 
> macro(find_package)
>   list(FIND PROJECTS_IN_WORKSPACE "${ARGV0}" found)
>   if(NOT found EQUAL -1)
>     _find_package(${ARGV})
>   endif()
> endmacro()
> 
> add_sundirectory(Foo)
> add_sundirectory(Bar)

Yes, but here also the project has to be aware of whether it has to 
find_package() the dependency or not, and this variant here is also not 
obviously easier than the one above using variables.

Alex




More information about the cmake-developers mailing list