|
Boost : |
Subject: Re: [boost] boost modularisation status?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-01-01 21:23:10
Le 02/01/12 01:44, Dave Abrahams a écrit :
> on Sun Jan 01 2012, "Vicente J. Botet Escriba"<vicente.botet-AT-wanadoo.fr> wrote:
>
>> Le 01/01/12 20:51, Eric Niebler a écrit :
>>> On 12/31/2011 5:37 PM, Dave Abrahams wrote:
>>>> on Sat Dec 31 2011, Dave Abrahams<dave-AT-boostpro.com> wrote:
>>>>
>>>>> on Sat Dec 31 2011, "Robert Ramey"<ramey-AT-rrsd.com> wrote:
>>>>>
>>>>>> https://svn.boost.org/trac/boost/wiki/CMakeModularizationStatus
>>>>>> hasn't been modified in 3 years.
>>>>>>
>>>>>> Also, when I peruse my local copy of the release tree, I don't see what I
>>>>>> expect to see according to
>>>>>> https://svn.boost.org/trac/boost/wiki/CMakeModularizeLibrary
>>> This page also needs to be updated or deleted.
>>>
>>>>>> That is, I expect to seem include inside of the libraries at
>>>>>> boost/libs/tr1/include - I don't see this.
>>>>>>
>>>>>> What is the current status of this?
>>>>> Glad you asked!
>>>>>
>>>>> That wiki page is (fortunately) out of date.
>>>> I've updated the Wiki page now. Please let me know what you think.
>>> I for one am glad to see this effort is ongoing. I'd like to see this
>>> project get more visibility as I see it as important for the long-term
>>> health of Boost. Can we put something on boost.org encouraging people to
>>> try out the (pre-alpha) modularlized boost distro, where to file bugs
>>> and how to get involved, etc?
>>>
>> Hi,
>>
>> this should be considered as a new tool (and in addition it needs
>> CMAKE build). While I consider the modularization useful, I find that
>> adding a new build system to Boost will need some official maintainers
>> of the CMake files for each one of the Boost libraries until the
>> library authors have taken the time to be familiar with the new build
>> system. Of course, this will imply that we need regular testers for
>> both build systems which will be time consuming
> I understand, but I disagree. There's no reason to make the (already
> high) hurdles to such a transition stratospherically high. If the Boost
> community decides to use any given new piece of infrastructure, there's
> no reason it has to be a protracted process; it can just happen.
Does this means that the library authors will need to maintain two build
systems?
>> Resuming, I think that we need a formal review for CMake build once it
>> is able to build the whole Boost libraries.
> Again I disagree. The review process is for libraries, and Boost has
> never formally reviewed tools like this. I am more than happy to have a
> discussion about it, and I believe that discussion should inform our
> decision, but I believe it is possible for the steering committee to
> make a decision as a matter of policy.
Oh, as lastly we have started to review also the tools I thought it
works like that also for a new build system, but you know better how
Boost works. I think it is time to start this discussion. Please could
the interested parties start a thread that results once for all in a
decision on whether CMake based build is adopted or not?
>
>> Is CMake build ready for review? If no, what is missing, not working
>> yet, ...?
> I think the Wiki page makes it pretty darned clear what the status is.
> Did you read the whole thing (particularly
> https://svn.boost.org/trac/boost/wiki/CMakeModularizationStatus#TODOs?)
>
No, I didn't read it before. I've read it now. I see that there is yet
some work to do yet. If the library authors should maintain the CMake
build system they could participate in the writing of these CMake files,
of course once the Boost community decide to adopt the new build system.
Note that I'm not completely against the adoption of CMake, as it could
have some advantages, but the liabilities should be considered also when
the decision will be taken. For that we need to start a discussion,
goals, documentation, who will take the decision, ....
Best,
Vicente
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk