[1.38] CMake support added to release branch?
I see from the 1.38 news section that experimental CMake support has been added to the release: I thought we were going to have a review before this happened? John Maddock.
On Sat, Jan 31, 2009 at 11:57 AM, John Maddock <john@johnmaddock.co.uk> wrote:
I see from the 1.38 news section that experimental CMake support has been added to the release: I thought we were going to have a review before this happened?
Hum... I must have missed that discussion, and OK'ed the request to merge. The CMake support is certainly experimental, but do you think there is any harm done by including it in the release in its current state? We can certainly publicize the fact that the support is experimental. --Beman
----- Original Message ----- From: "Beman Dawes" <bdawes@acm.org> To: <boost@lists.boost.org> Sent: Sunday, February 01, 2009 7:20 PM Subject: Re: [boost] [1.38] CMake support added to release branch?
On Sat, Jan 31, 2009 at 11:57 AM, John Maddock <john@johnmaddock.co.uk> wrote:
I see from the 1.38 news section that experimental CMake support has been added to the release: I thought we were going to have a review before this happened?
Hum... I must have missed that discussion, and OK'ed the request to merge.
The CMake support is certainly experimental, but do you think there is any harm done by including it in the release in its current state? We can certainly publicize the fact that the support is experimental.
Hi, I think that the inclusion of a experimental tool/library needs some explanations. Why CMake needs to be included on 1.38 as experimental? Who will experiment? and why she can not experiment from the sandbox? Which test cases have been runned and on which machines? Where can we get the documentation? What does it means "the support is experimental"? Can any developer add a non review library or tool as experimental on the distribution? Resuming, what makes CMake different from other tools/libraries? Thanks, Vicente
On Sat, Jan 31, 2009 at 11:57 AM, John Maddock <john@johnmaddock.co.uk>
I see from the 1.38 news section that experimental CMake support has been added to the release: I thought we were going to have a review before
wrote: this
happened?
Hum... I must have missed that discussion, and OK'ed the request to merge.
The CMake support is certainly experimental, but do you think there is any harm done by including it in the release in its current state? We can certainly publicize the fact that the support is experimental.
Hi, I think that the inclusion of a experimental tool/library needs some explanations.
Why CMake needs to be included on 1.38 as experimental? Who will experiment? and why she can not experiment from the sandbox? Which test cases have been runned and on which machines? Where can we get the documentation? What does it means "the support is experimental"? Can any developer add a non review library or tool as experimental on the distribution?
Resuming, what makes CMake different from other tools/libraries?
Thanks, Vicente
I have similar questions. I think it would be good if there is available some explanation/ background on CMake. What's it benefit (over existing bjam, etc.)? Will bjam be deprecated? and so on. Such explanations will make things much clearer and understandable. Thanks for your attention. B/Rgds Max
On Sat, Jan 31, 2009 at 11:57 AM, John Maddock <john@johnmaddock.co.uk> wrote:
I see from the 1.38 news section that experimental CMake support has been added to the release: I thought we were going to have a review before this happened?
Hum... I must have missed that discussion, and OK'ed the request to merge.
The CMake support is certainly experimental, but do you think there is any harm done by including it in the release in its current state? We can certainly publicize the fact that the support is experimental.
I guess really my concern is that folks don't read the docs ;-) So they'll see the CMake files and just go ahead and use them without realising that something experimental made it into the release. Has the CMake code merged to release been rigorously tested - or do we at least have a means to test it prior to release - for example to test the library build process? John.
John Maddock wrote:
So they'll see the CMake files and just go ahead and use them without realising that something experimental made it into the release.
Yeah, that clearly would happen, so the boost-cmake build won't let you proceed until you confirm that you understand the system is experimental. It looks like this: % cmake ../src -- The C compiler identification is GNU -- The CXX compiler identification is GNU -- Check for working C compiler: /usr/bin/gcc -- Check for working C compiler: /usr/bin/gcc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- ########################################################################## -- This cmake-based build system is currently under development. The -- bjam-based system is the 'standard' way to build boost. To try -- try out the cmake build, invoke CMake with the argument -- -DCMAKE_IS_EXPERIMENTAL=YES_I_KNOW -- Or use the gui to set the variable CMAKE_IS_EXPERIMENTAL to some value. -- This will only be necessary the first time. -- -- For more information on boost-cmake see the wiki: -- https://svn.boost.org/trac/boost/wiki/CMake -- -- Subscribe to the mailing list: -- http://lists.boost.org/mailman/listinfo.cgi/boost-cmake -- -- And/or check the archives: -- http://news.gmane.org/gmane.comp.lib.boost.cmake -- -- ########################################################################## CMake Error at CMakeLists.txt:54 (message): Magic variable CMAKE_IS_EXPERIMENTAL unset. -- Configuring done of course we can tweak the message as necessary. Maybe it should mention specifically to keep cmake chatter off of the main boost list.
Has the CMake code merged to release been rigorously tested
Yeah, as rigorously as one could given our resources (small)
or do we at least have a means to test it prior to release - for example to test the library build process?
Sure... just build boost with it. -t
troy d. straszheim wrote:
-- This cmake-based build system is currently under development. The -- bjam-based system is the 'standard' way to build boost. To try
Regardless of the main topic of this discussion, this statement needs fixing. First, "bjam-based" is technically wrong -- we use Boost.Build, and not some random other thing that happens to use bjam. Second, why is 'standard' quoted -- does that mean that 'standard' is not right term? I would suggest something like "Only Boost.Build is officially supported." will be more accurate. - Volodya
Beman Dawes wrote:
On Sat, Jan 31, 2009 at 11:57 AM, John Maddock <john@johnmaddock.co.uk> wrote:
I see from the 1.38 news section that experimental CMake support has been added to the release: I thought we were going to have a review before this happened?
Hum... I must have missed that discussion, and OK'ed the request to merge.
The CMake support is certainly experimental, but do you think there is any harm done by including it in the release in its current state? We can certainly publicize the fact that the support is experimental.
Currently, there are some things in the release which are not explicitly tested. Basically, these are test tools such as bjam of boost build, boost book, and perhaps others. Including CMake in the release would be consistent with current and recent practice. However, I believe the boost libraries could benefit by requiring that the same standards applied to libraries be applied to all tools delivered with the library. I see no justification for tools meeting a lessor standard than libraries. In one sense this isn't a huge deal as - at least in the case of build tools - they pretty well tested as a side effect of being used to test other libraries. But I think boost would benefit by setting the same high standard for libraries and tools. This standard would state: a) all released libraries and tools have been reviewed. b) all released libraries and tools are explicitly unit tested. c) all released libraries and tools meet some minimal standard for documentation and examples. So any user of the release would know that a) is it is meant to be used out of the box for production code. b) given the uniformly high standard to which all components are subjected, any failure, error, confusion regarding the documentation etc. is likely an error or oversight on the part of user and merits a more careful examination before raising the issue on the list. c) after consideration of b) above, any failure, error, confusion regarding the documentation etc. is unknown to boost developers and merits an error report. This will make it much more efficient to use boost. The alternative of having a policy of including expermental/untested/unreviewed code in the release is that every time the user has some sort of problem, he has to consider that the problem is not caused by him. Simple economics mean that he'll do the easiest first - query the list or assume its a known problem. Basically, once code that doesn't meet some standard is admitted, then every time a problem occurs, one has to consider the possibility that the code doesn't meet the normal standard and this takes a lot of time. To summarize: a) set standards for all components - tools and libraries in the release b) insist that all components meet the same standard. c) tell users a) and b) above and this release is the best we know how to do at the time of release. If one want's to create experimental "add-on" packages, that's fine - just don't package them in the release. These experimental add-on's can be on thier own track of development and be "mixed-in" at the user's discretion - assuming they are compatible with the public API of the libraries - which is another discussion we needn't go into there. Robert Ramey
--Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Sat, Jan 31, 2009 at 11:57 AM, John Maddock <john@johnmaddock.co.uk> wrote:
I see from the 1.38 news section that experimental CMake support has been added to the release: I thought we were going to have a review before this happened?
Hum... I must have missed that discussion, and OK'ed the request to merge.
The CMake support is certainly experimental, but do you think there is any harm done by including it in the release in its current state? We can certainly publicize the fact that the support is experimental.
Currently, there are some things in the release which are not explicitly tested. Basically, these are test tools such as bjam of boost build, boost book, and perhaps others. Including CMake in the release would be consistent with current and recent practice.
However, I believe the boost libraries could benefit by requiring that the same standards applied to libraries be applied to all tools delivered with the library. I see no justification for tools meeting a lessor standard than libraries.
In one sense this isn't a huge deal as - at least in the case of build tools - they pretty well tested as a side effect of being used to test other libraries. But I think boost would benefit by setting the same high standard for libraries and tools. This standard would state:
a) all released libraries and tools have been reviewed. b) all released libraries and tools are explicitly unit tested. c) all released libraries and tools meet some minimal standard for documentation and examples.
So any user of the release would know that
a) is it is meant to be used out of the box for production code. b) given the uniformly high standard to which all components are subjected, any failure, error, confusion regarding the documentation etc. is likely an error or oversight on the part of user and merits a more careful examination before raising the issue on the list. c) after consideration of b) above, any failure, error, confusion regarding the documentation etc. is unknown to boost developers and merits an error report.
This will make it much more efficient to use boost.
The alternative of having a policy of including expermental/untested/unreviewed code in the release is that every time the user has some sort of problem, he has to consider that the problem is not caused by him. Simple economics mean that he'll do the easiest first - query the list or assume its a known problem. Basically, once code that doesn't meet some standard is admitted, then every time a problem occurs, one has to consider the possibility that the code doesn't meet the normal standard and this takes a lot of time.
To summarize: a) set standards for all components - tools and libraries in the release b) insist that all components meet the same standard. c) tell users a) and b) above and this release is the best we know how to do at the time of release.
If one want's to create experimental "add-on" packages, that's fine - just don't package them in the release. These experimental add-on's can be on thier own track of development and be "mixed-in" at the user's discretion - assuming they are compatible with the public API of the libraries - which is another discussion we needn't go into there.
Robert Ramey
--Beman
Totally agree. An uniformed standard on coding, performance, compatibility and doc is important. B/Rgds Max
on Sun Feb 01 2009, "Max" <loadcom-AT-sina.com> wrote:
Totally agree. An uniformed standard on coding, performance, compatibility and doc is important.
I think Robert and Max may be right. Boost's reputation has spread quite a bit in recent years, and many more people are using it, and living up to that reputation is a much more serious business than it used to be. Even if Boost wants to remain "somewhat experimental," it could be very bad for our users (and, consequently, for us) if our official releases don't reflect tighter standards. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
on Sun Feb 01 2009, Beman Dawes <bdawes-AT-acm.org> wrote:
On Sat, Jan 31, 2009 at 11:57 AM, John Maddock <john@johnmaddock.co.uk> wrote:
I see from the 1.38 news section that experimental CMake support has been added to the release: I thought we were going to have a review before this happened?
Hum... I must have missed that discussion, and OK'ed the request to merge.
You and Doug and I discussed putting it in trunk when we were in San Francisco, but as for merging to release, I don't remember any such agreement. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (8)
-
Beman Dawes -
David Abrahams -
John Maddock -
Max -
Robert Ramey -
troy d. straszheim -
Vicente Botet -
Vladimir Prus