|
|
Boost Interest : |
From: Miguel A. Figueroa-Villanueva (miguelf_at_[hidden])
Date: 2008-07-02 03:41:15
Hello Doug,
On Wed, Jul 2, 2008 at 2:27 AM, Doug Gregor <doug.gregor_at_[hidden]> wrote:
> Hi Miguel,
>
> On Wed, Jul 2, 2008 at 1:12 AM, Miguel A. Figueroa-Villanueva wrote:
>> I would like to know what the current status of the boost cmake build
>> is. I guess that what I would like to know is where is this going?
>> I've tried to read the mailing list archives as much as possible, but
>> couldn't find a clear answer to the following:
>>
>> - Is there a chance that eventually people will realize how great the
>> cmake/ctest/cpack/cdash combination is as to drop the other build
>> system? Or is this highly unlikely? That is, are they meant to
>> co-exist?
>
> We're betting that people will realize that this build system is far
> better than the current Boost.Build, and offers a better way forward
> for Boost. Long-term, I don't believe that maintaining two build
> systems in Boost is desirable or feasible, and it is my goal to
> supplant Boost.Build version 2 completely within the next year. That
> said, I offer no guarantees: the Boost community could utterly reject
> what we're doing. (I see that as unlikely).
Fair enough. Actually, this is quite encouraging.
>> - Is the effort to modularize the libraries going to make it to the
>> trunk or is this going to remain a boost-cmake only thing?
>
> Well, doing it on the trunk either means that BBv2 also has to support
> modularization or that we have to drop Boost.Build. I'm not going to
> waste time doing the former, and we have to replace BBv2 before we can
> do the latter. Troy's actually working on a better way: by describing
> the headers for each library within the CMake description of that
> library, we can create CMake targets that automatically modularize a
> library (or, with a little more work, maybe even an entire Boost
> tree!). That way, we can co-exist with BBv2 but get the benefits of
> modularization as we go.
I guess your talking about the DEPENDS ... parameter passed to the
macro, right? 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.
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.
>> - Is there a CDash dashboard actively running? It seems that the
>> http://dart.resophonic.com/boost_1_34_0/Dashboard has been down for
>> the last 4 days at least...
>
> Troy's been working on an updated system that isn't based on CDash. I
> haven't been keeping up with it as well as I should, but I expect
> we'll see more cool stuff from him later on.
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 would like to try and help in the effort to modularize the libraries
>> (although I'm no boost expert... I do have some experience with the
>> cmake tool set) and to set up a dashboard.
>
> Great!
>
>> But I would like to know
>> what kind of support is this effort receiving from other boost
>> developers before I commit to this.
>
> Well, I can't give any guarantees. Troy and I are doing the major
> development work. David Abrahams and Beman Dawes are encouraging us
> and making sure that we cover some of the usability issues. Frankly, I
> think it will come down to the best technology winning, and we'll do
> the best we can to make sure that the CMake-based build system is the
> superior choice. I'm pretty sure we'll get there.
>
> Our short-term goal is to get everything building and testing properly
> for the upcoming Boost 1.36.0, where we hope to have some kind of
> CMake-based release for people to try. Additionally, we'll be building
> installers with CMake/CPack for both Windows and Mac, so that most
> Boost users won't even have to use a build system. (I've been spending
> most of my time on these installers, while Troy's been working on
> modularizing libraries and the testing system).
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.
--Miguel