|
|
Boost Interest : |
From: Doug Gregor (doug.gregor_at_[hidden])
Date: 2008-07-04 20:02:32
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?
> BTW, this modularization thing is cool, but I think it is a
> work-around until the files are modularized on the boost/trunk
> eventually when we switch to CMake completely ;)
Yes, it's a workaround, but we need to deal with the existing
infrastructure up until the point when we replace it. The fact that
modularization is getting so easy to use on the CMake side is a
really, really good sign that we're on the right track.
- Doug