|
|
Boost Interest : |
From: Doug Gregor (doug.gregor_at_[hidden])
Date: 2008-07-13 12:16:01
On Fri, Jul 4, 2008 at 8:02 PM, Doug Gregor <doug.gregor_at_[hidden]> wrote:
> Hi Miguel,
>
> On Thu, Jul 3, 2008 at 4:16 PM, Miguel A. Figueroa-Villanueva
> <miguelf_at_[hidden]> wrote:
>> I have attached a patch for your consideration. It basically removes
>> the dependency on modularize.py by using cmake commands. This should
>> work on any platform.
>
> Great! This worked well for me, and I definitely like replacing Python
> code with CMake code when possible.
>
> In looking at the patch, I don't think we want to do this:
>
> + else(EXISTS "${Boost_SOURCE_DIR}/boost/${item}")
> + MESSAGE(FATAL_ERROR
> + "Source file '${Boost_SOURCE_DIR}/boost/${item}' not available."
> + "Modularization might have moved it, please update your
> boost directory."
> + )
> + endif(EXISTS "${Boost_SOURCE_DIR}/boost/${item}")
>
> Since this code is run at configure time, this means that we can't
> configure an already-modularized tree. But, we want to configure (and
> build and test) a modularized tree to make sure that we have the
> module dependencies right. I suggest that there be an ELSEIF that
> checks whether the item exists in
> ${Boost_SOURCE_DIR}/libs/${libname}/include/boost/; if so, we're okay
> (it's already been modularized) and we probably don't even want to add
> the ${LIBNAME}-modularize target at all (since it's already been
> done!). If the item doesn't exist in either place, then we should
> error because the HEADERS list is incorrect. I didn't try to code this
> up; would you like to go ahead and do that?
I went ahead and hacked this up; it's in the tree now. Looks like we
have a bit of work to do to get all of the dependencies right. When I
saw some failures due to the inability to find boost/config.hpp, I
started wondering... should we define in advance what the "core" Boost
libraries are, and leave them non-modularized? Boost.Config seems like
the most core library of them all :)
Or, maybe it's just better to get *all* of the dependencies in there
now, and it'll be easier to maintain them afterward. Thoughts on these
two approaches?
- Doug