On 10/13/2013 02:30 PM, Joaquin M Lopez Munoz wrote:
Stephen Kelly
writes: That was done in this commit actually:
https://svn.boost.org/trac/boost/changeset/85272
That commit message doesn't specify the compiler versions affected either though, indeed.
You want this info to be spoken out oud and easily accessible; now it is hidden deep into one of your many recent commits (worse yet, 85275 was commited on your behalf by Daniel, so looking for skelly is not guaranteed to catch every relevant commit.)
My changes amount to removal of definitions of some macros in boost/config, followed by removal of newly-dead code. The log in boost/config is most relevant to what you seem to be looking for. There are very few changes there recently. I recommend using git-svn and `gitk boost/config`. I must confess I'm surprised at how few people on this list use git-svn. No one I know who has reached a certain familiarity with git would always use it over raw svn. Have you ever used git? I wonder will the git migration be beneficial/painful for this community. Or are you speaking for users, and not for yourself (I'm reading below)? I suppose you must be speaking for yourself as you talk about inadequate commit messages... My best advice to you is to use git-svn and gitk.
Considering that authors and, particularly, users do not customarily scan Boost commits at svn.boost.org, chances are the majority of affected people won't notice until Boost 1.56.
Ideas for improving that are welcome. Do you have any ideas? What about keeping http://www.boost.org/users/news/old_compilers.html up to date with the changes/bumps?
and one has to investigate in order to find out what other compilers are effecively dropped as a consequence of TPS being required (the log mentions MPW and SunPro 5.3, but I guess Digital Mars and GCC 2.x are also affected, Only the config/compiler files for MPW and SunPro are affected by this commit. Which are not listed in changeset 85272.
You don't understand. Maybe I was not clear enough. Let me try again: Only the config/compiler files for MPW and SunPro are affected by revision 86241. In that context, your comment about revision 85272 makes no sense. Do you understand now?
Are there other compilers affected?
This also makes no sense with the (hopefully?) clarity above. I answered this in the grandparent mail.
The DigitalMars one didn't define BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION, nor did it do so before revision 85272, so if it needed the macro, it was already broken. But at least one of your commits is related to Digital Mars:
What does one of my commits being related to Digital Mars have to do with revision 85272 or BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION? Please don't change the point of what we're discussing mid-thread. It's not fair to move the goalposts like that. Revision 86043 is not different to the commits which affected MSVC or GCC. I simplified a preprocessor condition for a compiler which has been marked as obsolete.
I have also the suspicion that along the way you have removed macros and workarounds not directly related to TPS or MSVC 6.0/7.0. Can you be more specific? Changeset 86043 was the one smelly commit I spotted.
It is not smelly. __DMC__ >= 0x810 is always true as of revision 85272.
* Consider adding some [xxx] subject tag in your communications to the mailing list so that users and maintainers can easily track them (for instance, [compiler support]) I'll never understand why people want '[compiler support]' prefixing a message titled 'Removing support for old compilers' (both keywords are there) or 'Bumping borland, SunPro, mwerks and MPW compiler requirements' (MPW is more-specific than 'compiler support', so if someone cares about MPW, that's what they'll notice). Prefixing, which is regularly used in Boost mailing lists, allows people interested in a particular initiative to easily filter and track related messages. Now, if I want to consult the prior discussions on your efforts I have to look for your name and filter out not related stuff.
Filtering for my name is enough. You can consider the [compiler support]/[modularization] implied on all messages from me. Thanks, Steve.