[1.34.0] Boost.Build
Hi, Please note that we are not going to ship boost.build v1 with 1.34.0. The only supported build system will be v2. Please notify me of any outstanding issues due to this. Thanks Thomas Release Manager -- Thomas Witt witt@acm.org
Hmmm - This is a surprise to me. The serialization library includes some shell scripts which users can use to test test their own archives. The scripts use v1. It would seem to me that that its not a great idea to make any change at all between the packages which are being tested as RC_1_34_0 and those to be released. Robert Ramey Thomas Witt wrote:
Hi,
Please note that we are not going to ship boost.build v1 with 1.34.0. The only supported build system will be v2. Please notify me of any outstanding issues due to this.
Thanks
Thomas
Release Manager
Robert Ramey wrote:
Hmmm - This is a surprise to me. The serialization library includes some shell scripts which users can use to test test their own archives. The scripts use v1. It would seem to me that that its not a great idea to make any change at all between the packages which are being tested as RC_1_34_0 and those to be released.
Most regression runners use V2 at the moment. As for the scripts -- you mean runtest.sh? Then, it's not a big problem: 1. Remove ALL_LOCATE_TARGET setting 2. Change -sTOOLS= to toolset= 3. Add --v2 option to process_jam_logs and compiler_status. In fact, I don't know what is compiler_status2 program is -- I don't see any by this name in tools directory. Did you some local changes and then added '2' to the name? If so, those tests won't run with vanilla Boost anyway, or am I missing something? - Volodya
It would seem to me that that its not a great idea to make any change at all between the packages which are being tested as RC_1_34_0 and those to be released.
Most regression runners use V2 at the moment.
As for the scripts -- you mean runtest.sh? Then, it's not a big problem:
1. Remove ALL_LOCATE_TARGET setting 2. Change -sTOOLS= to toolset= 3. Add --v2 option to process_jam_logs and compiler_status.
Could you give a pointer to the V2 documentation with gems such as this already noted so that library authors and users alike can test out the new RC and modify a few of our own projects that use boost build V1. I'm slightly surprised that boost build V1 is 'disappearing' because I also see it as a boost library, something that users have been using for larger projects. Can you point me to where it stated in previous releases or on the website that v1 wouldn't be available for this release. Perhaps a period of 'deprecated' but available might be in order. I'm not disagreeing that from a maintenance point of view, boost itself should all build with v2 and be the way forward, just that removing v1 support in Robert's script rather than keeping a v1 copy in a deprecated area may be problematic to people who have large developments built on v1. I'm not even suggesting V1 need be actively supported as an alternative in v1.34 of boost, just that it isn't actively removed. I've been trying to keep an eye on build v2 and there's been a lot of fantastic work, but I believe its only recently that its user documentation has been catching up. Much as I am concerned about my suggestion delaying the next boost release, is it worth discussing this on say the users list to gauge just how many users would be affected by an active removal of V1 support. Paul
Paul Baxter wrote: [snip]
I'm slightly surprised that boost build V1 is 'disappearing' because I also see it as a boost library, something that users have been using for larger projects. Can you point me to where it stated in previous releases or on the website that v1 wouldn't be available for this release. Perhaps a period of 'deprecated' but available might be in order.
I'm not disagreeing that from a maintenance point of view, boost itself should all build with v2 and be the way forward, just that removing v1 support in Robert's script rather than keeping a v1 copy in a deprecated area may be problematic to people who have large developments built on v1. I'm not even suggesting V1 need be actively supported as an alternative in v1.34 of boost, just that it isn't actively removed.
FWIW, I agree. Keeping BBv1 in CVS and instead making BBv2 the default when executing "bjam" for this release would be easier on the users, in combination with adding support for "bjam --v1". Perhaps also some deprecation warnings should be output when building with v1. BBv1 could then be removed from Boost CVS in 1.35 and made available as a separate download (tgz, zip). / Johan
Johan Nilsson wrote:
Paul Baxter wrote:
FWIW, I agree.
Keeping BBv1 in CVS and instead making BBv2 the default when executing "bjam" for this release would be easier on the users, in combination with adding support for "bjam --v1". Perhaps also some deprecation warnings should be output when building with v1.
BBv1 could then be removed from Boost CVS in 1.35 and made available as a separate download (tgz, zip).
That are all valid points, but at the end of the day we just don't have the resources. We can barely support one build system. FWIW users that depend on v1 can always use 1.33.x Thomas -- Thomas Witt witt@acm.org
Paul Baxter wrote:
It would seem to me that that its not a great idea to make any change at all between the packages which are being tested as RC_1_34_0 and those to be released.
Most regression runners use V2 at the moment.
As for the scripts -- you mean runtest.sh? Then, it's not a big problem:
1. Remove ALL_LOCATE_TARGET setting 2. Change -sTOOLS= to toolset= 3. Add --v2 option to process_jam_logs and compiler_status.
Could you give a pointer to the V2 documentation with gems such as this already noted so that library authors and users alike can test out the new RC and modify a few of our own projects that use boost build V1.
(3) is outside of Boost.Build completely -- and I'm not sure that compiler_status works at all now. (2) is documented at: http://boost.org/boost-build2/doc/html/bbv2/advanced/differences_to_v1/build... (1) Is not documented everywhere, unfortunately. - Volodya
Vladimir Prus <ghost@cs.msu.su> writes:
1. Remove ALL_LOCATE_TARGET setting 2. Change -sTOOLS= to toolset= 3. Add --v2 option to process_jam_logs and compiler_status.
It's not that straight-forward. You need to configure your toolsets in user-config.jam, and you need to be aware that the names have changed (e.g. msvc-7.1 rather than vc-7_1). There may be something else that I've missed, too. Anthony -- Anthony Williams Software Developer Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk
Vladimir Prus wrote:
Robert Ramey wrote:
Hmmm - This is a surprise to me. The serialization library includes some shell scripts which users can use to test test their own archives. The scripts use v1. It would seem to me that that its not a great idea to make any change at all between the packages which are being tested as RC_1_34_0 and those to be released.
Most regression runners use V2 at the moment.
As for the scripts -- you mean runtest.sh? Then, it's not a big problem:
1. Remove ALL_LOCATE_TARGET setting 2. Change -sTOOLS= to toolset= 3. Add --v2 option to process_jam_logs and compiler_status.
OK thanks for this.
In fact, I don't know what is compiler_status2 program is -- I don't see any by this name in tools directory. Did you some local changes and then added '2' to the name?
Yes, the modified source is in the vault.
If so, those tests won't run with vanilla Boost anyway, or am I missing something?
OK. This isn't a HUGE problem. But my larger point is that once the decision is made to "branch for release" then only the last bug fixes should go into the branch. In my view it was a grave error to "branch for release" and then declare - we're going to release with V2. Much better would be to say: Hence forth in the HEAD - only V2 will be used. Then after a while when the HEAD seems to be running pretty smoothly, then "branch for release" and make the last changes. In other words changes/additions for features shouldn't be made in a release branch. That ends up consuming lots of time. Robert Ramey
Robert, Robert Ramey wrote:
Vladimir Prus wrote:
Robert Ramey wrote:
But my larger point is that once the decision is made to "branch for release" then only the last bug fixes should go into the branch. In my view it was a grave error to "branch for release" and then declare - we're going to release with V2. Much better would be to say: Hence forth in the HEAD - only V2 will be used. Then after a while when the HEAD seems to be running pretty smoothly, then "branch for release" and make the last changes.
Sounds good. We'll try this approach the next time.
In other words changes/additions for features shouldn't be made in a release branch. That ends up consuming lots of time.
Agreed. FWIW the decision to use v2 was made a long time ago. Thomas PS: What's the status with respect to outstanding serialization regressions. Is there anything I can do to help get these fixed? -- Thomas Witt witt@acm.org
Thomas Witt wrote:
FWIW the decision to use v2 was made a long time ago.
The decision was made AFTER the branch for release. When this branch was made it was explicitly stated that only bug fixes should be commited to the release branch. This admonition was ignored when the decision to commit to v2 was made, which was not a bug fix but a feature enhancement. I'm sure this opened the door to more subtle feature enancements whch has resulted in a release branch lifetime of 10 months rather than say one month. Honestly, it hasn't hurt me personally. I've refrained from commiting anything other than bug fixes to the release branch. I doubt I've made more than 10 alterations in the relase branch since it was announced. It is a pity though that when 1.34 comes out, it will be a year away before the features/fixes now in the head appear in the next release.
Thomas
PS: What's the status with respect to outstanding serialization regressions. Is there anything I can do to help get these fixed?
I've concluded that all ounstanding serializaton regressions are not addressable with changes from within the serialization library. So anything not passing now shuold be marked as "expected failure" These last failures are one of the following: the Jamfiles depend on the toolset name to avoid running tests which will fail on systems without support for wide character i/o. CW 8.3 passes/fails and switches back and forth without any changes on my part. hp acc - has recently started to pass when a user sent me a patch to the test header. The current failures suggest something amiss with the testing environment. a couple of demos - fast_archive, portable archive don't pass when auto-linking is used. They conflict with auto-link in a fundamental way so can't really be fixed. I'll add A few borland 5.82 tests fail because they depend upon features in other libraries (mpl, variant) that fail with ths compiler. I guess these last should be noted in expected failures - I was hoping to see the failures disappear as thier root causes were addressed. Robert Ramey
"Robert Ramey" <ramey@rrsd.com> writes:
Thomas Witt wrote:
FWIW the decision to use v2 was made a long time ago.
The decision was made AFTER the branch for release.
No, it was made LONG before the branch.
When this branch was made it was explicitly stated that only bug fixes should be commited to the release branch.
We were talking about C++ code.
This admonition was ignored when the decision to commit to v2 was made, which was not a bug fix but a feature enhancement. I'm sure this opened the door to more subtle feature enancements whch has resulted in a release branch lifetime of 10 months rather than say one month.
The switch to v2 may have slowed us down by a couple of weeks at most.
Thomas
PS: What's the status with respect to outstanding serialization regressions. Is there anything I can do to help get these fixed?
I've concluded that all ounstanding serializaton regressions are not addressable with changes from within the serialization library. So anything not passing now shuold be marked as "expected failure"
So mark them.
These last failures are one of the following:
the Jamfiles depend on the toolset name to avoid running tests which will fail on systems without support for wide character i/o.
That's certainly fixable within the library.
CW 8.3 passes/fails and switches back and forth without any changes on my part.
hp acc - has recently started to pass when a user sent me a patch to the test header.
What do you mean by "the test header?"
The current failures suggest something amiss with the testing environment.
Did you report that to the tester?
a couple of demos - fast_archive, portable archive don't pass when auto-linking is used. They conflict with auto-link in a fundamental way
How so?
so can't really be fixed.
I doubt that; you could explicitly disasble auto-link for those tests.
I'll add
A few borland 5.82 tests fail because they depend upon features in other libraries (mpl, variant) that fail with ths compiler.
I guess these last should be noted in expected failures - I was hoping to see the failures disappear as thier root causes were addressed.
Not every library can support every feature on a broken compiler. It's up to you to deal with that in your own library, by either working around the problem yourself, or by explicitly declaring the functionality that depends on the other library to be broken with that compiler (i.e. marking the failure expected). -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Robert Ramey" <ramey@rrsd.com> writes:
hp acc - has recently started to pass when a user sent me a patch to the test header.
What do you mean by "the test header?"
serialization/test/test_tools.hpp
The current failures suggest something amiss with the testing environment.
Did you report that to the tester?
The tester saw it :-) As I said in my previous reply, it was some intermittent I/O problem: the compiler could not open STL include files. It disappeared as mysteriously as it appeared: for the past two tests run, serialization library is all green. Boris, the "tester" ----- Original Message ----- From: "David Abrahams" <dave@boost-consulting.com> To: <boost@lists.boost.org> Sent: Sunday, November 12, 2006 11:58 AM Subject: Re: [boost] [1.34.0] Boost.Build
"Robert Ramey" <ramey@rrsd.com> writes:
Thomas Witt wrote:
FWIW the decision to use v2 was made a long time ago.
The decision was made AFTER the branch for release.
No, it was made LONG before the branch.
When this branch was made it was explicitly stated that only bug fixes should be commited to the release branch.
We were talking about C++ code.
This admonition was ignored when the decision to commit to v2 was made, which was not a bug fix but a feature enhancement. I'm sure this opened the door to more subtle feature enancements whch has resulted in a release branch lifetime of 10 months rather than say one month.
The switch to v2 may have slowed us down by a couple of weeks at most.
Thomas
PS: What's the status with respect to outstanding serialization regressions. Is there anything I can do to help get these fixed?
I've concluded that all ounstanding serializaton regressions are not addressable with changes from within the serialization library. So anything not passing now shuold be marked as "expected failure"
So mark them.
These last failures are one of the following:
the Jamfiles depend on the toolset name to avoid running tests which will fail on systems without support for wide character i/o.
That's certainly fixable within the library.
CW 8.3 passes/fails and switches back and forth without any changes on my part.
hp acc - has recently started to pass when a user sent me a patch to the test header.
What do you mean by "the test header?"
The current failures suggest something amiss with the testing environment.
Did you report that to the tester?
a couple of demos - fast_archive, portable archive don't pass when auto-linking is used. They conflict with auto-link in a fundamental way
How so?
so can't really be fixed.
I doubt that; you could explicitly disasble auto-link for those tests.
I'll add
A few borland 5.82 tests fail because they depend upon features in other libraries (mpl, variant) that fail with ths compiler.
I guess these last should be noted in expected failures - I was hoping to see the failures disappear as thier root causes were addressed.
Not every library can support every feature on a broken compiler. It's up to you to deal with that in your own library, by either working around the problem yourself, or by explicitly declaring the functionality that depends on the other library to be broken with that compiler (i.e. marking the failure expected).
-- Dave Abrahams Boost Consulting www.boost-consulting.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
David Abrahams wrote:
"Robert Ramey" <ramey@rrsd.com> writes:
These last failures are one of the following:
the Jamfiles depend on the toolset name to avoid running tests which will fail on systems without support for wide character i/o.
That's certainly fixable within the library.
Hmm - I was never able to do it reliably for v1 maybe with V2 this can be made to work.
hp acc - has recently started to pass when a user sent me a patch to the test header.
What do you mean by "the test header?"
The serialization tests in include a local common header for dealing with things like creating temporary files which vary among environments.
The current failures suggest something amiss with the testing environment.
Did you report that to the tester?
No. I thought it was obvious from looking at the results. And apparently it has been as these types of problems seem to disappear as mysteriously as they appear.
a couple of demos - fast_archive, portable archive don't pass when auto-linking is used. They conflict with auto-link in a fundamental way
How so?
I forget the details. I did spend some time on it and that was my conclusion. Its related to the fact that creating a DLL which exports a new interface - like portable_binary simultaneously imports one from the library like binary.
so can't really be fixed.
I doubt that;
at least by me.
you could explicitly disasble auto-link for those tests.
I was of the idea that runing auto-linking would create one set of libraries with the "auto-linking" type names while not using auto-linking would create more generic names. So I thought that all the test suite had to be run the same way. Also, even assuimg it was a good idea, it wasn't clear to me how to do that. Now that we're moving to v2, I'll take another look.
A few borland 5.82 tests fail because they depend upon features in other libraries (mpl, variant) that fail with ths compiler.
I guess these last should be noted in expected failures - I was hoping to see the failures disappear as thier root causes were addressed.
Not every library can support every feature on a broken compiler. It's up to you to deal with that in your own library, by either working around the problem yourself, or by explicitly declaring the functionality that depends on the other library to be broken with that compiler (i.e. marking the failure expected).
Well, these failures appeared - but now they've gone - Along with one that had been hanging round for 10 months. I really can't be constantly marking/unmarking stuff. I think it would be best to wait until everyone has done what he can then do the marking. Robert Ramey
"Robert Ramey" <ramey@rrsd.com> writes:
David Abrahams wrote:
"Robert Ramey" <ramey@rrsd.com> writes:
These last failures are one of the following:
the Jamfiles depend on the toolset name to avoid running tests which will fail on systems without support for wide character i/o.
That's certainly fixable within the library.
Hmm - I was never able to do it reliably for v1 maybe with V2 this can be made to work.
Sorry, I assumed that you meant the problem was that the toolset names have changed; it would be easy to adjust the Jamfiles for that. Actually, it should be easy to use v2's "target alternatives" feature to exclude certain tests from the suite depending on toolset.
a couple of demos - fast_archive, portable archive don't pass when auto-linking is used. They conflict with auto-link in a fundamental way
How so?
I forget the details.
That sounds familiar. Don't you write these things down?
I did spend some time on it and that was my conclusion. Its related to the fact that creating a DLL which exports a new interface - like portable_binary simultaneously imports one from the library like binary.
so can't really be fixed.
I doubt that;
at least by me.
you could explicitly disasble auto-link for those tests.
I was of the idea that runing auto-linking would create one set of libraries with the "auto-linking" type names while not using auto-linking would create more generic names.
I don't think so.
So I thought that all the test suite had to be run the same way.
Nope
Also, even assuimg it was a good idea, it wasn't clear to me how to do that.
just use BOOST_ALL_NO_LIB, unless I'm misunderstanding what you're trying to do.
Now that we're moving to v2, I'll take another look.
I guess these last should be noted in expected failures - I was hoping to see the failures disappear as thier root causes were addressed.
Not every library can support every feature on a broken compiler. It's up to you to deal with that in your own library, by either working around the problem yourself, or by explicitly declaring the functionality that depends on the other library to be broken with that compiler (i.e. marking the failure expected).
Well, these failures appeared - but now they've gone - Along with one that had been hanging round for 10 months. I really can't be constantly marking/unmarking stuff. I think it would be best to wait until everyone has done what he can then do the marking.
Absolutely. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
"Robert Ramey" <ramey@rrsd.com> writes:
Actually, it should be easy to use v2's "target alternatives" feature to exclude certain tests from the suite depending on toolset.
The problem is that the the toolset name doesn't reliably convey the needed information. Specifically, there are tests which are pointless to run if the platform doesn't handle wide character i/o. Some versions of gcc implement it - others don't. And I can't figure out how to know with certainty in all cases. What I'm thinking about is more along the lines of the following: There would be a test as part of "config" group which results passes if wide char i/o is supported on the platform. Then, using "dependency" facilty - new in v2 I believe, condition the tests which require wide char i/o on the successful passing of the wide char i/o test. I'm not sure if v2 can be setup for this but this is what I would like to do. In fact, I would like to extend the concept even further. There isn't much point in running serialization tests on say - variant, if the other more basic tests for variant aren't all passing. So I would think it valuable to condition these tests also. All this required investigation and experiment - certainly not something appropriate for a "release" branch.
a couple of demos - fast_archive, portable archive don't pass when auto-linking is used. They conflict with auto-link in a fundamental way
How so?
I forget the details.
That sounds familiar. Don't you write these things down?
Not as much as I should. But in this particular case, some information can be found in the serialization documentation: Reference/Implemenation Notes/Compiler/Library Issues/VC++7.1 Robert Ramey
Thomas Witt schrieb:
The only supported build system will be v2. Please notify me of any outstanding issues due to this.
I have reported, that the bbv2 generates a different set of libraries as did bbv1. http://thread.gmane.org/gmane.comp.lib.boost.build/14381/focus=14381 I am not sure if this already has been solved, at least I did not hear an answer to my last posting on the issue. Roland
Roland Schwarz wrote:
Thomas Witt schrieb:
The only supported build system will be v2. Please notify me of any outstanding issues due to this.
I have reported, that the bbv2 generates a different set of libraries as did bbv1.
http://thread.gmane.org/gmane.comp.lib.boost.build/14381/focus=14381
I am not sure if this already has been solved, at least I did not hear an answer to my last posting on the issue.
FWIW, that issue is on top of my Boost.Build queue. I have a patch for one of the problems (lack of un-versioned links) in my local tree, finished, and will commit it later today. I'll then look at the second problem ("mt" not added with msvc). - Volodya
Vladimir Prus wrote:
Roland Schwarz wrote:
Thomas Witt schrieb:
The only supported build system will be v2. Please notify me of any outstanding issues due to this. I have reported, that the bbv2 generates a different set of libraries as did bbv1.
http://thread.gmane.org/gmane.comp.lib.boost.build/14381/focus=14381
I am not sure if this already has been solved, at least I did not hear an answer to my last posting on the issue.
FWIW, that issue is on top of my Boost.Build queue.
Also FWIW, the install issues Volodya is not dealing with are at the top of my TODO list. Fixed two of them earlier today :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Thomas Witt wrote:
Hi,
Please note that we are not going to ship boost.build v1 with 1.34.0. The only supported build system will be v2. Please notify me of any outstanding issues due to this.
I too find this decision abrupt, mistimed and unfortunate. V2 still misses boost specific documentation (!!) - the "Getting started" pages still refer to v1; as far as I know the local test reporting tools have been broken without plans for replacement; V2 itself still appears not to be ready for release. All this is going to delay 1.34 even further. :-( Cheers, Nicola Musatti
Nicola Musatti <Nicola.Musatti@gmail.com> writes:
Thomas Witt wrote:
Hi,
Please note that we are not going to ship boost.build v1 with 1.34.0. The only supported build system will be v2. Please notify me of any outstanding issues due to this.
I too find this decision abrupt,
It's an old, old decision. Sorry you didn't hear about it before.
mistimed
Why?
and unfortunate.
Why?
V2 still misses boost specific documentation (!!)
What do you mean by "boost specific documentation?"
- the "Getting started" pages still refer to v1;
Fixing that now.
as far as I know the local test reporting tools
What tools are those?
have been broken without plans for replacement; V2 itself still appears not to be ready for release.
Neither is v1, nor has it ever been. BBv1 has never really tried to be a Boost "product," but merely an internal tool. BBv2 strives to be really usable outside of Boost, and is in that sense much closer to being "ready for release" than v1.
All this is going to delay 1.34 even further. :-(
Why do you think so? -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (11)
-
Anthony Williams -
Boris Gubenko -
David Abrahams -
Johan Nilsson -
Nicola Musatti -
Paul Baxter -
Rene Rivera -
Robert Ramey -
Roland Schwarz -
Thomas Witt -
Vladimir Prus