Boost logo

Boost Interest :

From: Doug Gregor (doug.gregor_at_[hidden])
Date: 2008-07-02 04:05:45

Hello Miguel,

On Wed, Jul 2, 2008 at 3:41 AM, Miguel A. Figueroa-Villanueva
<miguelf_at_[hidden]> wrote:
> I guess your talking about the DEPENDS ... parameter passed to the
> macro, right?

Yes, the DEPENDS argument that shows up in the module.cmake file needs
to list all of the libraries that this library depends on.

> We would still have to list the sources of each library
> to get it working, though. Right now, the process installs the entire
> boost header directory. If we truly want to support components we need
> to install only the selected libs and its dependencies.

Right, so what Troy has done is to add a HEADERS argument to
boost_library_project that will be used to list all of the headers in
a project. One lists the top-level headers (e.g., signals.hpp) and any
directory names containing other headers (e.g., "signals"). That way,
we've identified which headers are part of the library and can
automatically move these into the right place as part of

> I was playing around trying to get the boost::any library compiled
> with cmake and along the way I realized it depends on: config,
> type_traits, static_assert, and throw_exception, which depend on mpl,
> detail, and preprocessor.
> I suppose that it would be nice if we select to install only the
> boost::any library and the system collects all the sources of these
> header-only libs and installs only that.

This is *exactly* what we're working on. At this point, we have enough
support for CMake so that users get a graphical installer on Mac and
Windows that allows them to choose which libraries to install
(including separate options for headers, specific library variants,
etc.), and the installers even encode the information from DEPENDS so
that you get a consistent installation. Select "any", and it'll
install type_traits, static_assert, mpi, etc. as well.

> I'd like to know the details here... if it is ctest/CDash I can help
> to set these up and later in august I could probably setup a public
> dashboard (Now the network administrator that is in charge of the
> equipment is in vacation and I need him to resize the virtualized qemu
> image).

I'm going to have to punt to Troy on this one.

> I suppose that work is being done on /branches/CMake/release, right?


> I'll check on the tickets in the trac and see if I can help with any.

We would appreciate the help. Our "TODO" list is here:

  - Doug

Boost-cmake list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at