[cmake-developers] Fwd: EXPORT_NAME-genex

[Daniel Pfeifer]

2013/5/25 Alexander Neundorf <neundorf at kde.org>

> 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 EQUALS -1)
> >     _find_package(${ARGV})
> >   endif()
> > endmacro()
> >
> > add_subdirectory(Foo)
> > add_subdirectory(Bar)
>
> Yes, but here also the project has to be aware of whether it has to
> find_package() the dependency or not,


No. Each project should *always* find_package() its dependencies, otherwise
it cannot be build standalone.
By overriding find_package() in the top level CMakeLists.txt file, this
command is turned into a noop for all projects that are part of the
workspace.


> and this variant here is also not
> obviously easier than the one above using variables.
>

Maybe. It's more about flexibility than ease of use.

Cheers, Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20130526/6b168add/attachment.html>