Re: [boost] [1.34.0] Boost.Build
[mailto:boost-bounces@lists.boost.org] On Behalf Of Thomas Witt 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
Doesn't this seem rather Microsoft-ish? I'm thinking of .NET, the attitude was you wouldn't accept it when we offered it to you so now we're going to force it on you. And, if you really don't want .NET you can always use VC6.5. Do you see the parallels here? If it has to go away, and I'm not saying for a moment that it shouldn't, v1 should at least be formally deprecated for one release cycle so as not to catch the users off guard. Matt Scanned by McAfee GroupShield {X3BTB534}
Matt Doyle wrote:
[mailto:boost-bounces@lists.boost.org] On Behalf Of Thomas Witt
FWIW users that depend on v1 can always use 1.33.x
Doesn't this seem rather Microsoft-ish? I'm thinking of .NET, the attitude was you wouldn't accept it when we offered it to you so now we're going to force it on you. And, if you really don't want .NET you can always use VC6.5. Do you see the parallels here?
There is one significant difference, Boost.Build is not a Boost library. It's a tool Boost uses to make the the distribution and building easier. I.e. BB is independent of the Boost releases.
If it has to go away, and I'm not saying for a moment that it shouldn't, v1 should at least be formally deprecated for one release cycle so as not to catch the users off guard.
BBv1 has been in deprecation status for more than 8 months now (I don't really remember that far back, so it may be even longer). And it will still be deprecated after the 1.34.0 release. It just won't be included with the release. If any one want to use it, it will still be available in CVS. The *big* caveats are that it is no longer supported (inside nor outside of Boost). And Boost libraries will no longer use it. So in a sense this is more like MFC, if you must insist on using Microsoft references ;-) -- -- 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
Rene Rivera wrote:
Matt Doyle wrote:
[mailto:boost-bounces@lists.boost.org] On Behalf Of Thomas Witt
FWIW users that depend on v1 can always use 1.33.x
Doesn't this seem rather Microsoft-ish? I'm thinking of .NET, the attitude was you wouldn't accept it when we offered it to you so now we're going to force it on you. And, if you really don't want .NET you can always use VC6.5. Do you see the parallels here?
There is one significant difference, Boost.Build is not a Boost library. It's a tool Boost uses to make the the distribution and building easier. I.e. BB is independent of the Boost releases.
If it is then it should have been developed separately, tested, released and only then integrated into Boost, at the start of the first subsequent release cycle. As it is Boost appears to be a gigantic unit test for Boost.Build. Cheers, Nicola Musatti
Nicola Musatti wrote:
Rene Rivera wrote:
Matt Doyle wrote:
[mailto:boost-bounces@lists.boost.org] On Behalf Of Thomas Witt FWIW users that depend on v1 can always use 1.33.x Doesn't this seem rather Microsoft-ish? I'm thinking of .NET, the attitude was you wouldn't accept it when we offered it to you so now we're going to force it on you. And, if you really don't want .NET you can always use VC6.5. Do you see the parallels here? There is one significant difference, Boost.Build is not a Boost library. It's a tool Boost uses to make the the distribution and building easier. I.e. BB is independent of the Boost releases.
If it is then it should have been developed separately, tested, released and only then integrated into Boost, at the start of the first subsequent release cycle. As it is Boost appears to be a gigantic unit test for Boost.Build.
We did do that for BBv2, or I should say mostly Volodya has done that. BBv2 has had releases now for more than 3 years <http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=80982>. And has seen most of it's use outside Boost for those 3 years. -- -- 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
Rene Rivera wrote:
Nicola Musatti wrote: [...] We did do that for BBv2, or I should say mostly Volodya has done that. BBv2 has had releases now for more than 3 years <http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=80982>. And has seen most of it's use outside Boost for those 3 years.
I'm aware of that and I can imagine the amount of work that went into it. However it looks like it was integrated into Boost and used to replace v1 way to soon. As it is the impression is that the price of this integration is being paid by all those that are cooperating in trying and complete 1.34 . Even this wouldn't be so bad had it taken place right after 1.33.1 (or 1.34, for that matter) was released. As it is completing the switch when the release is some six months behind of schedule is only going to cause further delays. Moreover the fact that this switch had actually started many months ago - witness Dave Abrahams stating that he stopped updating v1 Jamfiles long ago - is just additional indication that this has been badly mishandled. Cheers, Nicola Musatti
Nicola Musatti <Nicola.Musatti@gmail.com> writes:
Rene Rivera wrote:
Nicola Musatti wrote: [...] We did do that for BBv2, or I should say mostly Volodya has done that. BBv2 has had releases now for more than 3 years <http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=80982>. And has seen most of it's use outside Boost for those 3 years.
I'm aware of that and I can imagine the amount of work that went into it. However it looks like it was integrated into Boost and used to replace v1 way to soon.
Why do you say so?
As it is the impression is that the price of this integration is being paid by all those that are cooperating in trying and complete 1.34.
How so?
Even this wouldn't be so bad had it taken place right after 1.33.1 (or 1.34, for that matter) was released.
As it is completing the switch when the release is some six months behind of schedule is only going to cause further delays.
Why do you think so?
Moreover the fact that this switch had actually started many months ago - witness Dave Abrahams stating that he stopped updating v1 Jamfiles long ago - is just additional indication that this has been badly mishandled.
Why is that an indication that it has been badly mishandled? Can you point to any actual problems this change is causing, and if so, do you have any constructive suggestions for addressing them? -- Dave Abrahams Boost Consulting www.boost-consulting.com
Nicola Musatti <Nicola.Musatti@gmail.com> writes:
Rene Rivera wrote:
Boost.Build is not a Boost library. It's a tool Boost uses to make the the distribution and building easier. I.e. BB is independent of the Boost releases.
If it is then it should have been developed separately, tested, released and only then integrated into Boost, at the start of the first subsequent release cycle.
Sorry you weren't around to tell us how to do it right when we started the project. We did the best we could with the knowledge we had at the time. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (4)
-
David Abrahams -
Matt Doyle -
Nicola Musatti -
Rene Rivera