On Fri, Jul 4, 2008 at 8:02 PM, Doug Gregor <[EMAIL PROTECTED]> wrote:
> Hi Miguel,
>
> On Thu, Jul 3, 2008 at 4:16 PM, Miguel A. Figueroa-Villanueva
> <[EMAIL PROTECTED]> 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
_______________________________________________
Boost-cmake mailing list
Boost-cmake@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-cmake

Reply via email to