[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