|
Boost : |
From: Paul Baxter (pauljbaxter_at_[hidden])
Date: 2006-11-10 04:03:00
>> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk