Removing old config macro and increasing compiler requirements.
Hi there, I've been working on the modularization effort from a CMake point of view, and from an 'actual modularization' point of view, looking at interdependencies: http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/9/focus=26 I'd like to start on reducing interdependencies, and I'd like to start reasonably small, as no-one in the boost community knows me and see how it goes from there. I'm very active in CMake, Qt and KDE. Currently, in the modularized boost repos, boost::config and boost::core depend on each other. I listed 3 ways of fixing this on the ryppl list: http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/201 My preference is the removal of BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS, and requiring compilers to have the feature. That way boost/config/suffix.hpp will no longer need to include boost/{non_,}type.hpp. My preference is increasing the compiler requirement, because that may open up more similar opportunities for reducing dependencies and interdependencies throughout boost. Grepping indicates that that means increasing the compiler requirements to something like __DMC__ > 0x840, GCC > 3.2, BOOST_INTEL_CXX_VERSION > 500, VC++ > 7.0. Comments? Thanks, Steve.
On 29 July 2013 12:17, Stephen Kelly wrote:
Grepping indicates that that means increasing the compiler requirements to something like __DMC__ > 0x840, GCC > 3.2, BOOST_INTEL_CXX_VERSION > 500, VC++ > 7.0.
As anecdata, I can think of **very** few times people ask for help with GCC <= 3.2 on the gcc-help mailing list or on other fora I sometimes read. Anyone who does ask for help with such ancient compilers is invariably told to stop using them.
On Jul 29, 2013, at 4:17 AM, Stephen Kelly <steveire@gmail.com> wrote:
Hi there,
I've been working on the modularization effort from a CMake point of view, and from an 'actual modularization' point of view, looking at interdependencies:
http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/9/focus=26
I'd like to start on reducing interdependencies, and I'd like to start reasonably small, as no-one in the boost community knows me and see how it goes from there. I'm very active in CMake, Qt and KDE.
Currently, in the modularized boost repos, boost::config and boost::core depend on each other. I listed 3 ways of fixing this on the ryppl list:
http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/201
My preference is the removal of BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS, and requiring compilers to have the feature. That way boost/config/suffix.hpp will no longer need to include boost/{non_,}type.hpp.
My preference is increasing the compiler requirement, because that may open up more similar opportunities for reducing dependencies and interdependencies throughout boost.
Grepping indicates that that means increasing the compiler requirements to something like __DMC__ > 0x840, GCC > 3.2, BOOST_INTEL_CXX_VERSION > 500, VC++ > 7.0.
gcc 3.3 as a minimum seems ok to me. I'm a bit less sure about cutting out VC++ 7 - but we don't seem to have any testers for it. I don't have any opinion on the version bump for Digital Mars or Icc. That macro appears to be used in Boost.Python, Boost.PropertyMap, Boost.CRC, Boost.Math and Boost.MPL, and maybe other libraries. I assume you're volunteering to update them as well (and the Boost.config docs and tests, etc)? -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
Marshall wrote:
That macro appears to be used in Boost.Python, Boost.PropertyMap, Boost.CRC, Boost.Math and Boost.MPL, and maybe other libraries. I assume you're volunteering to update them as well (and the Boost.config docs and tests, etc)?
Yes. Any idea why I can't post to this list through gmane? Thanks, Steve.
On 7/29/2013 9:56 AM, Stephen Kelly wrote:
Marshall wrote:
That macro appears to be used in Boost.Python, Boost.PropertyMap, Boost.CRC, Boost.Math and Boost.MPL, and maybe other libraries. I assume you're volunteering to update them as well (and the Boost.config docs and tests, etc)?
Yes.
Any idea why I can't post to this list through gmane?
You need to post through GMane using the same e-mail address you used when you signed up for the mailing list. Perhaps you are not doing that. If you are doing it, the first time you try to post through GMane you will receive an e-mail asking you to confirm you exist simply by replying. Once you reply you then get another e-mail saying you can now post through GMane. Is it possible that your first prompt e-mail never gets to you because it ends up in your Junk folder ?
On 07/30/2013 02:22 AM, Edward Diener wrote:
On 7/29/2013 9:56 AM, Stephen Kelly wrote:
Marshall wrote:
That macro appears to be used in Boost.Python, Boost.PropertyMap, Boost.CRC, Boost.Math and Boost.MPL, and maybe other libraries. I assume you're volunteering to update them as well (and the Boost.config docs and tests, etc)?
Yes.
Any idea why I can't post to this list through gmane?
You need to post through GMane using the same e-mail address you used when you signed up for the mailing list. Perhaps you are not doing that. If you are doing it, the first time you try to post through GMane you will receive an e-mail asking you to confirm you exist simply by replying. Once you reply you then get another e-mail saying you can now post through GMane. Is it possible that your first prompt e-mail never gets to you because it ends up in your Junk folder ?
Yes, I'm aware of the process. I use GMane for almost all mailing lists. It doesn't work for ryppl, and now it doesn't work for boost either. I didn't get any 'authorization required' mail from GMane when I first posted. I also checked my junk folder. Thanks, Steve.
On 07/29/2013 01:17 PM, Stephen Kelly wrote:
Grepping indicates that that means increasing the compiler requirements to something like __DMC__ > 0x840, GCC > 3.2, BOOST_INTEL_CXX_VERSION > 500, VC++ > 7.0.
Please see the attached patches. One of them bumps the compiler requirement, but far too conservatively. I'd suggest bumping it far more. Having such a low compiler requirement means that in some cases workarounds are needed for libraries which do not otherwise need the workarounds. Such workarounds are implemented using other boost libraries, and therefore some lateral dependencies between libraries exist purely because of the low minimum compiler requirement. If you want to modularize properly, you'll have to cut such lateral dependencies, and that means updating the compiler requirement. Users of ancient compilers can use ancient boost, right? Thanks, Steve.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Stephen Kelly Sent: Wednesday, July 31, 2013 1:58 PM To: boost@lists.boost.org Subject: Re: [boost] Removing old config macro and increasing compiler requirements.
On 07/29/2013 01:17 PM, Stephen Kelly wrote:
Grepping indicates that that means increasing the compiler requirements to something like __DMC__ > 0x840, GCC > 3.2, BOOST_INTEL_CXX_VERSION > 500, VC++ > 7.0.
Please see the attached patches. One of them bumps the compiler requirement, but far too conservatively. I'd suggest bumping it far more. Having such a low compiler requirement means that in some cases workarounds are needed for libraries which do not otherwise need the workarounds. Such workarounds are implemented using other boost libraries, and therefore some lateral dependencies between libraries exist purely because of the low minimum compiler requirement.
If you want to modularize properly, you'll have to cut such lateral dependencies, and that means updating the compiler requirement. Users of ancient compilers can use ancient boost, right?
Right. Is a reason for reluctance to do this (apart from the work involved) that we have no very effective way of warning users of these compilers ahead of time? Posting on the web site isn't much good because people don't study it - and it is clutter for most who are using other compilers. Can we produce a "skull-and-bones" compile-time message on the lines of "This is the last time that this will work!"? To catch people's attention, using an soon-to-be obsolete compiler or feature would have to produce an compile-fail error at first, but one that could be countermanded by users then making some macro definition meaning "I have read and understood the previous warning" so that it would compile. This would loudly warn that this is the last version of Boost that will work, so they can either stick to that version, or upgrade compiler etc. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow@hetp.u-net.com
On 31 July 2013 14:32, Paul A. Bristow wrote:
Can we produce a "skull-and-bones" compile-time message on the lines of "This is the last time that this will work!"?
To catch people's attention, using an soon-to-be obsolete compiler or feature would have to produce an compile-fail error at first, but one that could be countermanded by users then making some macro definition meaning "I have read and understood the previous warning" so that it would compile.
This would loudly warn that this is the last version of Boost that will work, so they can either stick to that version, or upgrade compiler etc.
Although I think that's better than nothing, it doesn't help people who upgrade from, for example, 1.54 to 1.56 and skip the 1.55 version with the warning. In my experience many users only upgrade Boost occasionally, rather than at every release. To help those people later versions could replace the "This is the last time that this will work!" message that can be disabled via a macro with a message that can't be disabled saying "Boost 1.xx is the last version that supports your compiler"
On 07/31/2013 03:32 PM, Paul A. Bristow wrote:
To catch people's attention, using an soon-to-be obsolete compiler or feature would have to produce an compile-fail error at first, but one that could be countermanded by users then making some macro definition meaning "I have read and understood the previous warning" so that it would compile.
This would loudly warn that this is the last version of Boost that will work, so they can either stick to that version, or upgrade compiler etc.
That could be an option. Timing is difficult though. I still believe, as I wrote before http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/201/focus=2... that modularization should be done before repo-splitting into many (35 in the case of attempting to use boost::any) interdependent repos. For clarity for readers, the reply from Dave about KDE modularization seems to be referring to migrating from svn to git and the tool used for that, not kdelibs modularization. The svn to git migration happened several years ago, but the modularization of the existing kdelibs.git is a separate ongoing effort which will eventually result in multiple separate git repos. It is being done along with porting from Qt 4 to Qt 5: http://community.kde.org/Frameworks/Epics I know the migration from boost svn to multiple interdependent git repos will be done before 'actual' modularization, but I'd like to see what useful modularization steps can be done before that. I really really dislike git submodules, and I dislike working with more git submodules more :). Thanks, Steve.
on Wed Jul 31 2013, Stephen Kelly <steveire-AT-gmail.com> wrote:
On 07/31/2013 03:32 PM, Paul A. Bristow wrote:
To catch people's attention, using an soon-to-be obsolete compiler or feature would have to produce an compile-fail error at first, but one that could be countermanded by users then making some macro definition meaning "I have read and understood the previous warning" so that it would compile.
This would loudly warn that this is the last version of Boost that will work, so they can either stick to that version, or upgrade compiler etc.
That could be an option. Timing is difficult though. I still believe, as I wrote before
http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/201/focus=2...
that modularization should be done before repo-splitting into many (35 in the case of attempting to use boost::any) interdependent repos.
Why do you believe that? It seems to me much, much easier to untangle undesired dependencies after the repositories are split.
For clarity for readers, the reply from Dave about KDE modularization seems to be referring to migrating from svn to git and the tool used for that, not kdelibs modularization. The svn to git migration happened several years ago, but the modularization of the existing kdelibs.git is a separate ongoing effort which will eventually result in multiple separate git repos. It is being done along with porting from Qt 4 to Qt 5:
http://community.kde.org/Frameworks/Epics
I know the migration from boost svn to multiple interdependent git repos will be done before 'actual' modularization, but I'd like to see what useful modularization steps can be done before that. I really really dislike git submodules, and I dislike working with more git submodules more :).
Git submodules are not part of the long-term plan, at least, not for most developers. The idea is that the ryppl tool prepares a workspace for you that includes all of the dependencies. The code surely doesn't work right now, but that's what we implemented in http://github.com/ryppl/ryppl, and I expect to ressurrect that work after the Boost SVN->Git transition is complete. -- Dave Abrahams
On 08/03/2013 11:08 PM, Dave Abrahams wrote:
on Wed Jul 31 2013, Stephen Kelly <steveire-AT-gmail.com> wrote:
That could be an option. Timing is difficult though. I still believe, as I wrote before
http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/201/focus=2...
that modularization should be done before repo-splitting into many (35 in the case of attempting to use boost::any) interdependent repos. Why do you believe that? It seems to me much, much easier to untangle undesired dependencies after the repositories are split.
A personal bias I suppose :). I don't know why you think it's much much easier to do post-split, but I guess the reason doesn't matter too much and it's manageable either way. Thanks, Steve.
on Sun Aug 04 2013, Stephen Kelly <steveire-AT-gmail.com> wrote:
On 08/03/2013 11:08 PM, Dave Abrahams wrote:
on Wed Jul 31 2013, Stephen Kelly <steveire-AT-gmail.com> wrote:
That could be an option. Timing is difficult though. I still believe, as I wrote before
http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/201/focus=2...
that modularization should be done before repo-splitting into many (35 in the case of attempting to use boost::any) interdependent repos. Why do you believe that? It seems to me much, much easier to untangle undesired dependencies after the repositories are split.
A personal bias I suppose :). I don't know why you think it's much much easier to do post-split, but I guess the reason doesn't matter too much and it's manageable either way.
Well, I guess it's only *much* easier post-ryppl, which is further down the road. At that point, all dependencies will be explicitly declared and each library author will have independent control. -- Dave Abrahams
on Wed Jul 31 2013, Stephen Kelly <steveire-AT-gmail.com> wrote:
On 07/29/2013 01:17 PM, Stephen Kelly wrote:
Grepping indicates that that means increasing the compiler requirements to something like __DMC__ > 0x840, GCC > 3.2, BOOST_INTEL_CXX_VERSION > 500, VC++ > 7.0.
Please see the attached patches. One of them bumps the compiler requirement, but far too conservatively. I'd suggest bumping it far more. Having such a low compiler requirement means that in some cases workarounds are needed for libraries which do not otherwise need the workarounds. Such workarounds are implemented using other boost libraries, and therefore some lateral dependencies between libraries exist purely because of the low minimum compiler requirement.
If you want to modularize properly, you'll have to cut such lateral dependencies, and that means updating the compiler requirement. Users of ancient compilers can use ancient boost, right?
+1 -- Dave Abrahams
on Mon Jul 29 2013, Stephen Kelly <steveire-AT-gmail.com> wrote:
Hi there,
I've been working on the modularization effort from a CMake point of view, and from an 'actual modularization' point of view, looking at interdependencies:
http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/9/focus=26
I'd like to start on reducing interdependencies, and I'd like to start reasonably small, as no-one in the boost community knows me and see how it goes from there. I'm very active in CMake, Qt and KDE.
Currently, in the modularized boost repos, boost::config and boost::core depend on each other. I listed 3 ways of fixing this on the ryppl list:
http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/201
My preference is the removal of BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS, and requiring compilers to have the feature. That way boost/config/suffix.hpp will no longer need to include boost/{non_,}type.hpp.
This seems entirely reasonable to me.
My preference is increasing the compiler requirement, because that may open up more similar opportunities for reducing dependencies and interdependencies throughout boost.
Grepping indicates that that means increasing the compiler requirements to something like __DMC__ > 0x840,
I'd be shocked if any version of that compiler worked with any substantial fraction of the Boost codebase.
GCC > 3.2, BOOST_INTEL_CXX_VERSION > 500, VC++ > 7.0.
+1 -- Dave Abrahams
On 08/03/2013 11:03 PM, Dave Abrahams wrote:
on Mon Jul 29 2013, Stephen Kelly <steveire-AT-gmail.com> wrote:
My preference is increasing the compiler requirement, because that may open up more similar opportunities for reducing dependencies and interdependencies throughout boost.
Grepping indicates that that means increasing the compiler requirements to something like __DMC__ > 0x840, I'd be shocked if any version of that compiler worked with any substantial fraction of the Boost codebase.
Ok, then the patch I posted which was specific to that compiler should be fine.
GCC > 3.2, BOOST_INTEL_CXX_VERSION > 500, VC++ > 7.0. +1
What do you think about increasing the compiler requirement much more, as I wrote in another mail? Thanks, Steve.
On Sun, 4 Aug 2013, at 10:22 AM, Stephen Kelly wrote:
What do you think about increasing the compiler requirement much more, as I wrote in another mail?
I'd say no, unless you've got a very good reason. Compiler support should be an individual library maintainers decision.
On 08/04/2013 10:57 AM, Daniel James wrote:
On Sun, 4 Aug 2013, at 10:22 AM, Stephen Kelly wrote:
What do you think about increasing the compiler requirement much more, as I wrote in another mail? I'd say no, unless you've got a very good reason. Compiler support should be an individual library maintainers decision.
Thanks for bringing that up. I was hoping someone would :). I've been reading the boost mailing list for a while and I've seen similar sentiments that each maintainer can make somewhat autonomous decisions on things like this. That obviously does not help with forward momentum in efforts like this, and I expect the boost community has a solution to that problem. Is the solution the steering committee? I ask because I'm not familiar enough with the boost community to know already. Thanks, Steve.
On Aug 4, 2013, at 5:51 AM, Stephen Kelly <steveire@gmail.com> wrote:
On 08/04/2013 10:57 AM, Daniel James wrote:
On Sun, 4 Aug 2013, at 10:22 AM, Stephen Kelly wrote:
What do you think about increasing the compiler requirement much more, as I wrote in another mail? I'd say no, unless you've got a very good reason. Compiler support should be an individual library maintainers decision.
Thanks for bringing that up. I was hoping someone would :). I've been reading the boost mailing list for a while and I've seen similar sentiments that each maintainer can make somewhat autonomous decisions on things like this.
We generally favor library-specific decisions when reasonable.
That obviously does not help with forward momentum in efforts like this, and I expect the boost community has a solution to that problem.
When it becomes necessary to make a decision that affects multiple libraries, we try to gain consensus on this list. If there is a person or group with authority over the aspect under discussion, like the Release Managers or Review Wizards, they would decide.
Is the solution the steering committee?
The Steering Committee would only get involved when a decision is required and the foregoing options fail to render an acceptable decision. ___ Rob (Sent from my portable computation engine)
(This was a bit delayed as I accidentally sent this off list first time) On Sun, 4 Aug 2013, at 11:51 AM, Stephen Kelly wrote:
On 08/04/2013 10:57 AM, Daniel James wrote:
On Sun, 4 Aug 2013, at 10:22 AM, Stephen Kelly wrote:
What do you think about increasing the compiler requirement much more, as I wrote in another mail? I'd say no, unless you've got a very good reason. Compiler support should be an individual library maintainers decision.
Thanks for bringing that up. I was hoping someone would :). I've been reading the boost mailing list for a while and I've seen similar sentiments that each maintainer can make somewhat autonomous decisions on things like this.
Usually by me I imagine.
That obviously does not help with forward momentum in efforts like this, and I expect the boost community has a solution to that problem.
Do you have any evidence for that? No one opposed your original change. I didn't because the benefit outweighed the potential loss (which is very small, possibly none at all). But "increasing the compiler requirement much more" sounds excessive.
Is the solution the steering committee? I ask because I'm not familiar enough with the boost community to know already.
It's not really very clear what the situation is, at least to me. But I'd say that such things really should be discussed on this list first as it's a development matter.
On 08/04/2013 12:57 PM, Daniel James wrote:
That obviously does not help with forward momentum in efforts like this, and I expect the boost community has a solution to that problem. Do you have any evidence for that? No one opposed your original change.
I don't have specific information on what minimum compiler version would enable which interdependency culling, no. I only have the hard information that increasing the requirement allows cutting the config->core dependency, and the any->static_assert dependency. It is not unreasonable to think that the pattern ends there, so I don't think further evidence is necessary. I think what is necessary is for the boost community to pick increased compiler requirements for the purpose of proceeding with modularization, and I recommend increasing the requirement significantly in order to make most significant cuts in interdependencies.
I didn't because the benefit outweighed the potential loss (which is very small, possibly none at all). But "increasing the compiler requirement much more" sounds excessive.
Is the solution the steering committee? I ask because I'm not familiar enough with the boost community to know already. It's not really very clear what the situation is, at least to me. But I'd say that such things really should be discussed on this list first as it's a development matter.
Yes. Thanks, Steve.
On Sun, 4 Aug 2013, at 01:00 PM, Stephen Kelly wrote:
I don't have specific information on what minimum compiler version would enable which interdependency culling, no. I only have the hard information that increasing the requirement allows cutting the config->core dependency, and the any->static_assert dependency.
It is not unreasonable to think that the pattern ends there, so I don't think further evidence is necessary.
I don't buy that. Config is a special case, since almost everything depends on it.
On 08/04/2013 01:10 PM, Daniel James wrote:
On Sun, 4 Aug 2013, at 01:00 PM, Stephen Kelly wrote:
I don't have specific information on what minimum compiler version would enable which interdependency culling, no. I only have the hard information that increasing the requirement allows cutting the config->core dependency, and the any->static_assert dependency.
It is not unreasonable to think that the pattern ends there, so I don't think further evidence is necessary. I don't buy that. Config is a special case, since almost everything depends on it.
Are you ignoring what I wrote about any->static_assert dependency which is no longer needed as a result of bumping the compiler requirement? Anyway, I think I'm starting to repeat myself in this thread, so I think that's enough on that topic for the moment. I agree that there seems to be consensus on the patches that I already posted. Getting those committed would be a step in the right direction, and as I wrote, enable other cleanups such as the any->static_assert dependency. If those patches can be committed I can look into removing that dependency and investigate other consequences of the version requirement bump. http://thread.gmane.org/gmane.comp.lib.boost.devel/243094/focus=243125 I do still want to see the compiler version bumped higher, but that's something for you guys who are stakeholders in the boost community to hash out, and something that can be done in parallel to my work if those patches get committed. So, if someone with the commit bit can commit those, let's progress in parallel. Thanks, Steve.
On Sun, 4 Aug 2013, at 01:21 PM, Stephen Kelly wrote:
On 08/04/2013 01:10 PM, Daniel James wrote:
On Sun, 4 Aug 2013, at 01:00 PM, Stephen Kelly wrote:
I don't have specific information on what minimum compiler version would enable which interdependency culling, no. I only have the hard information that increasing the requirement allows cutting the config->core dependency, and the any->static_assert dependency.
It is not unreasonable to think that the pattern ends there, so I don't think further evidence is necessary. I don't buy that. Config is a special case, since almost everything depends on it.
Are you ignoring what I wrote about any->static_assert dependency which is no longer needed as a result of bumping the compiler requirement?
I don't think it matters. static_assert is a tiny dependency.
On 08/04/2013 01:31 PM, Daniel James wrote:
On Sun, 4 Aug 2013, at 01:21 PM, Stephen Kelly wrote:
On 08/04/2013 01:10 PM, Daniel James wrote:
On Sun, 4 Aug 2013, at 01:00 PM, Stephen Kelly wrote:
I don't have specific information on what minimum compiler version would enable which interdependency culling, no. I only have the hard information that increasing the requirement allows cutting the config->core dependency, and the any->static_assert dependency.
It is not unreasonable to think that the pattern ends there, so I don't think further evidence is necessary. I don't buy that. Config is a special case, since almost everything depends on it. Are you ignoring what I wrote about any->static_assert dependency which is no longer needed as a result of bumping the compiler requirement? I don't think it matters. static_assert is a tiny dependency.
You miss the point entirely, repeatedly and insistently :). Hopefully someone else will react to the request to commit the patches. Thanks, Steve.
On Sun, 4 Aug 2013, at 01:45 PM, Stephen Kelly wrote:
Hopefully someone else will react to the request to commit the patches.
I was just reviewing them. You need to post with '[config]' in the title to get John's blessing.
On 08/04/2013 01:55 PM, Daniel James wrote:
On Sun, 4 Aug 2013, at 01:45 PM, Stephen Kelly wrote:
Hopefully someone else will react to the request to commit the patches. I was just reviewing them. You need to post with '[config]' in the title to get John's blessing.
Thanks, Steve.
on Sun Aug 04 2013, Stephen Kelly <steveire-AT-gmail.com> wrote:
On 08/04/2013 01:31 PM, Daniel James wrote:
On Sun, 4 Aug 2013, at 01:21 PM, Stephen Kelly wrote:
On 08/04/2013 01:10 PM, Daniel James wrote:
On Sun, 4 Aug 2013, at 01:00 PM, Stephen Kelly wrote:
I don't have specific information on what minimum compiler version would enable which interdependency culling, no. I only have the hard information that increasing the requirement allows cutting the config->core dependency, and the any->static_assert dependency.
It is not unreasonable to think that the pattern ends there, so I don't think further evidence is necessary. I don't buy that. Config is a special case, since almost everything depends on it. Are you ignoring what I wrote about any->static_assert dependency which is no longer needed as a result of bumping the compiler requirement? I don't think it matters. static_assert is a tiny dependency.
You miss the point entirely, repeatedly and insistently :).
Stephen, I don't think you're being quite fair here. I am trying hard to see your point, and if there's something Daniel has missed, well, I guess I am probably missing it too. Could you patiently try again to spell out your point in the simplest and clearest terms possible? Thanks, -- Dave Abrahams
On 08/05/2013 04:32 PM, Dave Abrahams wrote:
on Sun Aug 04 2013, Stephen Kelly <steveire-AT-gmail.com> wrote:
On 08/04/2013 01:31 PM, Daniel James wrote:
On Sun, 4 Aug 2013, at 01:21 PM, Stephen Kelly wrote:
On 08/04/2013 01:10 PM, Daniel James wrote:
On Sun, 4 Aug 2013, at 01:00 PM, Stephen Kelly wrote:
I don't have specific information on what minimum compiler version would enable which interdependency culling, no. I only have the hard information that increasing the requirement allows cutting the config->core dependency, and the any->static_assert dependency.
It is not unreasonable to think that the pattern ends there, so I don't think further evidence is necessary. I don't buy that. Config is a special case, since almost everything depends on it. Are you ignoring what I wrote about any->static_assert dependency which is no longer needed as a result of bumping the compiler requirement? I don't think it matters. static_assert is a tiny dependency. You miss the point entirely, repeatedly and insistently :). Stephen, I don't think you're being quite fair here. I am trying hard to see your point, and if there's something Daniel has missed, well, I guess I am probably missing it too. Could you patiently try again to spell out your point in the simplest and clearest terms possible?
Roughly backwards through what I've quoted above: Forget that static_assert is a small dependency. My point was that increasing the compiler requirement makes one library not depend on the other in at least two cases (config->core and any->static_assert, and to some extent, but not a full extent, any->type_traits). The core->config issue is not a special case, because the exact same case exists for any->static_assert. To be clear, the 'case' is that 'when we bump compiler requirements, we can remove library dependencies'. The compiler requirement bump I posted patches for has benefits and very small impact, so should be a no-brainer and independently justifiable. I haven't investigated other benefits of doing the bump, but just running 'git grep -w 1300' in boost-trunk shows me that there will be more code and workarounds to remove. How that can possibly be a can of worms I still don't know... I can just wait and see if someone commits my patches after whatever process or user surveys you want to do, then I can investigate more. Thanks, Steve.
on Mon Aug 05 2013, Stephen Kelly <steveire-AT-gmail.com> wrote:
On 08/05/2013 04:32 PM, Dave Abrahams wrote:
on Sun Aug 04 2013, Stephen Kelly <steveire-AT-gmail.com> wrote:
On 08/04/2013 01:31 PM, Daniel James wrote:
On Sun, 4 Aug 2013, at 01:21 PM, Stephen Kelly wrote:
On 08/04/2013 01:10 PM, Daniel James wrote:
Roughly backwards through what I've quoted above:
Forget that static_assert is a small dependency.
My point was that increasing the compiler requirement makes one library not depend on the other in at least two cases (config->core and any->static_assert, and to some extent, but not a full extent, any->type_traits).
The core->config issue is not a special case, because the exact same case exists for any->static_assert.
To be clear, the 'case' is that 'when we bump compiler requirements, we can remove library dependencies'.
The compiler requirement bump I posted patches for has benefits and very small impact, so should be a no-brainer and independently justifiable.
I haven't investigated other benefits of doing the bump, but just running 'git grep -w 1300' in boost-trunk shows me that there will be more code and workarounds to remove. How that can possibly be a can of worms I still don't know...
OK.
I can just wait and see if someone commits my patches after whatever process or user surveys you want to do, then I can investigate more.
For my part, I think the changes you proposed so far should be considered uncontroversial and simply applied without further opinion-gathering. -- Dave Abrahams
on Sun Aug 04 2013, Stephen Kelly <steveire-AT-gmail.com> wrote:
On 08/04/2013 12:57 PM, Daniel James wrote:
That obviously does not help with forward momentum in efforts like this, and I expect the boost community has a solution to that problem. Do you have any evidence for that? No one opposed your original change.
I don't have specific information on what minimum compiler version would enable which interdependency culling, no. I only have the hard information that increasing the requirement allows cutting the config->core dependency, and the any->static_assert dependency.
It is not unreasonable to think that the pattern ends there,
Did you mean the opposite? I presume you are arguing that the pattern probably continues. (People who make non-trivial arguments shouldn't throw double-negatives?)
so I don't think further evidence is necessary.
"It is not unreasonable to think" doesn't demonstrate anything, so it's also (ahem) not unreasonable to want to see more evidence. :-)
I think what is necessary is for the boost community to pick increased compiler requirements for the purpose of proceeding with modularization,
Why is that necessary? Aren't individual library authors fully capable of making the decision to drop support for an old compiler because it's pulling in a dependency they don't really want? -- Dave Abrahams
On 08/05/2013 04:30 PM, Dave Abrahams wrote:
on Sun Aug 04 2013, Stephen Kelly <steveire-AT-gmail.com> wrote:
On 08/04/2013 12:57 PM, Daniel James wrote:
That obviously does not help with forward momentum in efforts like this, and I expect the boost community has a solution to that problem. Do you have any evidence for that? No one opposed your original change. I don't have specific information on what minimum compiler version would enable which interdependency culling, no. I only have the hard information that increasing the requirement allows cutting the config->core dependency, and the any->static_assert dependency.
It is not unreasonable to think that the pattern ends there, Did you mean the opposite? I presume you are arguing that the pattern probably continues.
Yes.
(People who make non-trivial arguments shouldn't throw double-negatives?)
Very good :).
so I don't think further evidence is necessary. "It is not unreasonable to think" doesn't demonstrate anything, so it's also (ahem) not unreasonable to want to see more evidence. :-)
I've looked at boost::any in an updated boost repo (mine was an obsolete boost-zero repo which has not been updated in a long time). The uses of other features of type_traits has grown there, so more modularization work would be needed. Actually I thought that upgrading the compiler requirement would be such a no-brainer as to require no further evidence of its usefulness than I already presented. If that's not the case, then *shrug*.
I think what is necessary is for the boost community to pick increased compiler requirements for the purpose of proceeding with modularization, Why is that necessary? Aren't individual library authors fully capable of making the decision to drop support for an old compiler because it's pulling in a dependency they don't really want?
If that's how boost works, then you're telling me :). Thanks, Steve.
on Mon Aug 05 2013, Stephen Kelly <steveire-AT-gmail.com> wrote:
On 08/05/2013 04:30 PM, Dave Abrahams wrote:
"It is not unreasonable to think" doesn't demonstrate anything, so it's also (ahem) not unreasonable to want to see more evidence. :-)
I've looked at boost::any in an updated boost repo (mine was an obsolete boost-zero repo which has not been updated in a long time). The uses of other features of type_traits has grown there, so more modularization work would be needed.
Not surprising.
Actually I thought that upgrading the compiler requirement would be such a no-brainer as to require no further evidence of its usefulness than I already presented. If that's not the case, then *shrug*.
Well, I can see it's useful in principle, but it's quite possible that once you get past the very oldest compilers, the wins from further narrowing compiler support drop sharply.
I think what is necessary is for the boost community to pick increased compiler requirements for the purpose of proceeding with modularization,
Why is that necessary? Aren't individual library authors fully capable of making the decision to drop support for an old compiler because it's pulling in a dependency they don't really want?
If that's how boost works, then you're telling me :).
That's how Boost works. One of the ideas of the Git separation (and hopefully eventual Ryppl) transition is to give maintainers more of a sense of control over these things. I'm sure the commitment to quality is there, but I think there's probably a lot of resignation over the seemingly-intractable morasse. -- Dave Abrahams
on Sun Aug 04 2013, Stephen Kelly <steveire-AT-gmail.com> wrote:
On 08/04/2013 10:57 AM, Daniel James wrote:
On Sun, 4 Aug 2013, at 10:22 AM, Stephen Kelly wrote:
What do you think about increasing the compiler requirement much more, as I wrote in another mail? I'd say no, unless you've got a very good reason. Compiler support should be an individual library maintainers decision.
Thanks for bringing that up. I was hoping someone would :). I've been reading the boost mailing list for a while and I've seen similar sentiments that each maintainer can make somewhat autonomous decisions on things like this. That obviously does not help with forward momentum in efforts like this, and I expect the boost community has a solution to that problem.
Is the solution the steering committee?
Yes, that was one of the main reason we formed it. -- Dave Abrahams
Daniel James skrev 2013-08-04 10:57:
On Sun, 4 Aug 2013, at 10:22 AM, Stephen Kelly wrote:
What do you think about increasing the compiler requirement much more, as I wrote in another mail?
I'd say no, unless you've got a very good reason. Compiler support should be an individual library maintainers decision.
Should it? If one library can be dependent on 35 others (boost::any?) it sure seems like an agreed upon base line could be useful. Bo Persson
On Sun, 4 Aug 2013, at 12:00 PM, Bo Persson wrote:
Daniel James skrev 2013-08-04 10:57:
On Sun, 4 Aug 2013, at 10:22 AM, Stephen Kelly wrote:
What do you think about increasing the compiler requirement much more, as I wrote in another mail?
I'd say no, unless you've got a very good reason. Compiler support should be an individual library maintainers decision.
Should it? If one library can be dependent on 35 others (boost::any?) it sure seems like an agreed upon base line could be useful.
That's an extra responsibility that the maintainer of boost::any takes on. That's surely well understood by now.
On Sun, 4 Aug 2013, at 12:20 PM, Daniel James wrote:
On Sun, 4 Aug 2013, at 12:00 PM, Bo Persson wrote:
Daniel James skrev 2013-08-04 10:57:
On Sun, 4 Aug 2013, at 10:22 AM, Stephen Kelly wrote:
What do you think about increasing the compiler requirement much more, as I wrote in another mail?
I'd say no, unless you've got a very good reason. Compiler support should be an individual library maintainers decision.
Should it? If one library can be dependent on 35 others (boost::any?) it sure seems like an agreed upon base line could be useful.
That's an extra responsibility that the maintainer of boost::any takes on. That's surely well understood by now.
Sorry, I confused dependents and dependencies there. The maintainer of Any can choose its dependencies. Btw. how did you get 35 for boost::any?
On 08/04/2013 12:26 PM, Daniel James wrote:
Sorry, I confused dependents and dependencies there. The maintainer of Any can choose its dependencies. Btw. how did you get 35 for boost::any?
Sure. boost::any depends on boost::config and boost::type_traits. The maintainer of boost::any does not get to choose the dependencies of those. The boost::type_traits library depends on boost::mpl and boost::preprocessor, etc, and the mesh is formed. Breaking the dependency of boost::config on boost::core (as my patches do) is significant for boost::any, because boost::any then depends only on boost::type_traits for remove_reference and is_reference, and on boost::static_assert. However, the static_assert and is_reference are only needed inside an ifdef for a compiler which my patch already removes support for (BOOST_MSVC,<=1300). That leaves only remove_reference. One could imagine splitting type_traits into two libraries so that the simple, common and essential traits like remove_reference live in a library which does not depend on boost::mpl or boost::preprocessor. However, looking properly into all of that is the 'next step', and I don't want to take multiple steps forward before even completing the first step with the patches I've already posted. I want to get the first step completed both to establish some credibility for me in the boost community, and to establish some credibility for the boost community in me - I need to believe that 'real modularization' can proceed with reasonable effort before investing lots of my time in it :). Thanks, Steve.
On 08/04/2013 12:00 PM, Bo Persson wrote:
Daniel James skrev 2013-08-04 10:57:
On Sun, 4 Aug 2013, at 10:22 AM, Stephen Kelly wrote:
What do you think about increasing the compiler requirement much more, as I wrote in another mail?
I'd say no, unless you've got a very good reason. Compiler support should be an individual library maintainers decision.
Should it? If one library can be dependent on 35 others (boost::any?) it sure seems like an agreed upon base line could be useful.
Note that the libraries are all in an interdependent mesh. So attempting to use any one of them (not just the 'any' one of them :) ) results in requiring all of them. http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/9/focus=26 http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/201 Thanks, Steve.
On Sun, 4 Aug 2013, at 12:27 PM, Stephen Kelly wrote:
On 08/04/2013 12:00 PM, Bo Persson wrote:
Daniel James skrev 2013-08-04 10:57:
On Sun, 4 Aug 2013, at 10:22 AM, Stephen Kelly wrote:
What do you think about increasing the compiler requirement much more, as I wrote in another mail?
I'd say no, unless you've got a very good reason. Compiler support should be an individual library maintainers decision.
Should it? If one library can be dependent on 35 others (boost::any?) it sure seems like an agreed upon base line could be useful.
Note that the libraries are all in an interdependent mesh. So attempting to use any one of them (not just the 'any' one of them :) ) results in requiring all of them.
http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/9/focus=26
I tried deleting the unordered library from my repo and could still run the any tests just fine. So unordered's compiler requirements don't affect boost::any's at all, even though it's in your list. Module dependencies are too coarse grained. They pull in a lot of transitive dependencies that don't affect actual use. Which is what determines compiler requirements.
On 08/04/2013 12:45 PM, Daniel James wrote:
Note that the libraries are all in an interdependent mesh. So attempting to use any one of them (not just the 'any' one of them :) ) results in requiring all of them.
http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/9/focus=26 I tried deleting the unordered library from my repo and could still run
On Sun, 4 Aug 2013, at 12:27 PM, Stephen Kelly wrote: the any tests just fine. So unordered's compiler requirements don't affect boost::any's at all, even though it's in your list. Module dependencies are too coarse grained. They pull in a lot of transitive dependencies that don't affect actual use. Which is what determines compiler requirements.
That's not unexpected. I expect you did not use an old enough/platform specific enough compiler to require all the conditional dependencies. For example, if you used GCC3.3+ boost::config does not depend on boost::core for you. My test was with the cmake-powered repos. Each library in those repos searches for all dependencies of each library as hard dependencies currently, so the list we arrive at is a union of hard and optional dependencies for all platforms and compilers. There is of course an argument for trying to encode optional dependencies in the CMake files, and I do think that should be done. However, this is a candle we can burn at both ends. Thanks, Steve.
On Sun, 4 Aug 2013, at 12:56 PM, Stephen Kelly wrote:
On 08/04/2013 12:45 PM, Daniel James wrote:
Note that the libraries are all in an interdependent mesh. So attempting to use any one of them (not just the 'any' one of them :) ) results in requiring all of them.
http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/9/focus=26 I tried deleting the unordered library from my repo and could still run
On Sun, 4 Aug 2013, at 12:27 PM, Stephen Kelly wrote: the any tests just fine. So unordered's compiler requirements don't affect boost::any's at all, even though it's in your list. Module dependencies are too coarse grained. They pull in a lot of transitive dependencies that don't affect actual use. Which is what determines compiler requirements.
That's not unexpected. I expect you did not use an old enough/platform specific enough compiler to require all the conditional dependencies. For example, if you used GCC3.3+ boost::config does not depend on boost::core for you.
But in terms of the compile, I believe config only depends on "boost/type.hpp" and "boost/non_type.hpp" from core, which both depend on nothing. So all the dependents pulled in by a modularization system do not affect the compiler requirements at all.
On 08/04/2013 01:08 PM, Daniel James wrote:
On Sun, 4 Aug 2013, at 12:56 PM, Stephen Kelly wrote:
On 08/04/2013 12:45 PM, Daniel James wrote:
Note that the libraries are all in an interdependent mesh. So attempting to use any one of them (not just the 'any' one of them :) ) results in requiring all of them.
http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/9/focus=26 I tried deleting the unordered library from my repo and could still run
On Sun, 4 Aug 2013, at 12:27 PM, Stephen Kelly wrote: the any tests just fine. So unordered's compiler requirements don't affect boost::any's at all, even though it's in your list. Module dependencies are too coarse grained. They pull in a lot of transitive dependencies that don't affect actual use. Which is what determines compiler requirements. That's not unexpected. I expect you did not use an old enough/platform specific enough compiler to require all the conditional dependencies. For example, if you used GCC3.3+ boost::config does not depend on boost::core for you. But in terms of the compile, I believe config only depends on "boost/type.hpp" and "boost/non_type.hpp" from core, which both depend on nothing.
Correct. But they are in the boost::core library along with other files which do have dependencies. Therefore as boost::config depends on boost::core for only those two files, boost::config gets all the dependencies of boost::core transitively. I'm actually even a bit confused by what you wrote because I thought this would be very obvious. Did I misunderstand what you wrote? Please see also what I wrote before about moving those files being a potential solution in this particular instance, but that increasing the compiler requirement is the better solution because it enables further modularization: http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/201
So all the dependents pulled in by a modularization system do not affect the compiler requirements at all.
I'm sorry, I don't understand what you're saying here. Thanks, Steve.
On Sun, 4 Aug 2013, at 01:14 PM, Stephen Kelly wrote:
On 08/04/2013 01:08 PM, Daniel James wrote:
So all the dependents pulled in by a modularization system do not affect the compiler requirements at all.
I'm sorry, I don't understand what you're saying here.
This was all in response to Bo Persson's post:
Should it? If one library can be dependent on 35 others (boost::any?) it sure seems like an agreed upon base line could be useful.
As I understood it the point was that because boost::any depends on 35 libraries, a common base line is required for all 35 libraries. But many of these libraries don't actually affect boost::any, so I don't the point holds - i.e. unordered could require gcc 4.5, but boost::any would continue to work with gcc 4.4. This is a separate issue to how compiler requirements affect modularization.
Correct. But they are in the boost::core library along with other files which do have dependencies. Therefore as boost::config depends on boost::core for only those two files, boost::config gets all the dependencies of boost::core transitively. I'm actually even a bit confused by what you wrote because I thought this would be very obvious.
Sorry, but there is no Boost core library other than what you have chosen to define - one could just as easily place those two files as part of Boost.Config and break the dependency that way. Just saying... John.
On 08/04/2013 02:09 PM, John Maddock wrote:
Correct. But they are in the boost::core library along with other files which do have dependencies. Therefore as boost::config depends on boost::core for only those two files, boost::config gets all the dependencies of boost::core transitively. I'm actually even a bit confused by what you wrote because I thought this would be very obvious.
Sorry, but there is no Boost core library other than what you have chosen to define
Correction: I did not define anything about boost::core. I'm referring to what is already the modularized layout, which afaik has already been agreed upon and is somewhat inevitable. That is what should be understood as the core library I refer to. The contents of that library are somewhat orthogonal though:
- one could just as easily place those two files as part of Boost.Config and break the dependency that way. Just saying...
Correct. I wrote as much before and linked to it in my original mail. http://thread.gmane.org/gmane.comp.lib.boost.devel/243094 I also referred to that since then here in the mail you quoted: http://thread.gmane.org/gmane.comp.lib.boost.devel/243094/focus=243218 Stephen Kelly wrote:
Please see also what I wrote before about moving those files being a
potential solution in this particular instance, but that increasing the
compiler requirement is the better solution because it enables further
modularization:
http://thread.gmane.org/gmane.comp.programming.tools.ryppl.devel/201
Ok, now I'm certain I'm just repeating myself :). That's not useful. Thanks, Steve.
On Sun, 4 Aug 2013, at 02:09 PM, John Maddock wrote:
Correct. But they are in the boost::core library along with other files which do have dependencies. Therefore as boost::config depends on boost::core for only those two files, boost::config gets all the dependencies of boost::core transitively. I'm actually even a bit confused by what you wrote because I thought this would be very obvious.
Sorry, but there is no Boost core library other than what you have chosen to define - one could just as easily place those two files as part of Boost.Config and break the dependency that way. Just saying...
Do you have an opinion on the original change? The only contentious part of it seems to be dropping Visual C++ 7.0.
Do you have an opinion on the original change? The only contentious part of it seems to be dropping Visual C++ 7.0.
Well I'm sort of sitting on the fence ;-) I suspect from a purely practical perspective, few libraries are still compatible with that compiler, so I'm inclined to agree we might as well drop support. Of course that opens a whole can of worms, because if we agreed to that then there's a whole slew of config macros (and associated workarounds) that can be removed. So I'm inclined to agree to whatever you want ;-) But perhaps more to the point we should be doing whatever our users want - so perhaps it would be better to open up a discussion on boost-users on which compilers we can drop and work from there. If I have a criticism of this current suggestion it's that the motivation is the wrong way around - in principle we shouldn't be dropping support for something just because it make modularization easier, even if in the end, dropping support for that feature may well be the right thing to do. Nit pickingly yours, John.
On Sun, 04 Aug 2013 09:48:11 -0700, John Maddock <john@johnmaddock.co.uk> wrote:
Do you have an opinion on the original change? The only contentious part of it seems to be dropping Visual C++ 7.0.
Well I'm sort of sitting on the fence ;-)
Nit pickingly yours, John.
Just to clarify, the (proposed) dropped support will be for Visual C++ 7.0 (which corresponds to Visual C++ 2002), but support will be maintained for Visual C++ 7.1 (which corresponds to Visual C++ 2003) and above?
On Mon, 5 Aug 2013, at 01:18 AM, Mostafa wrote:
On Sun, 04 Aug 2013 09:48:11 -0700, John Maddock <john@johnmaddock.co.uk> wrote:
Do you have an opinion on the original change? The only contentious part of it seems to be dropping Visual C++ 7.0.
Well I'm sort of sitting on the fence ;-)
Nit pickingly yours, John.
Just to clarify, the (proposed) dropped support will be for Visual C++ 7.0 (which corresponds to Visual C++ 2002), but support will be maintained for Visual C++ 7.1 (which corresponds to Visual C++ 2003) and above?
Yes, sort of. Visual C++ 7.0 will have a config error (which you can avoid by using a custom configuration file). Visual C++ 7.1 won't have a config error and we won't deliberately remove support, but support will be patchy. Many libraries (especially new ones) don't support that compiler, and we also don't have any formal testing for it, so if new changes break something, it might not be noticed.
On 08/04/2013 06:48 PM, John Maddock wrote:
Do you have an opinion on the original change? The only contentious part of it seems to be dropping Visual C++ 7.0.
Well I'm sort of sitting on the fence ;-)
I suspect from a purely practical perspective, few libraries are still compatible with that compiler, so I'm inclined to agree we might as well drop support. Of course that opens a whole can of worms, because if we agreed to that then there's a whole slew of config macros (and associated workarounds) that can be removed.
How is that 'a can of worms' rather than 'a good thing' ? Thanks, Steve.
I suspect from a purely practical perspective, few libraries are still compatible with that compiler, so I'm inclined to agree we might as well drop support. Of course that opens a whole can of worms, because if we agreed to that then there's a whole slew of config macros (and associated workarounds) that can be removed.
How is that 'a can of worms' rather than 'a good thing' ?
Well, can it not be both? ;-) John.
On 08/05/2013 10:33 AM, John Maddock wrote:
I suspect from a purely practical perspective, few libraries are still compatible with that compiler, so I'm inclined to agree we might as well drop support. Of course that opens a whole can of worms, because if we agreed to that then there's a whole slew of config macros (and associated workarounds) that can be removed.
How is that 'a can of worms' rather than 'a good thing' ?
Well, can it not be both? ;-)
No, it can't be a can of worms at all. It's simply a benefit/effect/consequence of bumping the compiler requirement. Thanks, Steve.
on Mon Aug 05 2013, Stephen Kelly <steveire-AT-gmail.com> wrote:
On 08/05/2013 10:33 AM, John Maddock wrote:
I suspect from a purely practical perspective, few libraries are still compatible with that compiler, so I'm inclined to agree we might as well drop support. Of course that opens a whole can of worms, because if we agreed to that then there's a whole slew of config macros (and associated workarounds) that can be removed.
How is that 'a can of worms' rather than 'a good thing' ?
Well, can it not be both? ;-)
No, it can't be a can of worms at all.
It's simply a benefit/effect/consequence of bumping the compiler requirement.
I think *maybe* John is worried about potential downstream code breakage from removing config macros. -- Dave Abrahams
On 08/05/2013 04:45 PM, Dave Abrahams wrote:
on Mon Aug 05 2013, Stephen Kelly <steveire-AT-gmail.com> wrote:
No, it can't be a can of worms at all.
It's simply a benefit/effect/consequence of bumping the compiler requirement. I think *maybe* John is worried about potential downstream code breakage from removing config macros.
Is it not obvious that obsolete macros can be kept and defined to nothing? Is it not obvious that obsolescence warnings or errors for obsolete macros can be added? #if defined(BOOST_STRICT_CONFIG) // BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENT is never defined. #else // Obsolete. Defined to nothing # define BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENT #endif Even the patches that I posted contain things like +// This macro is obsolete. Port away and remove. +# define BOOST_PYTHON_EXPLICIT_TT_DEF(T) If you are correct about the true concern, it would be nice to know so that it can be addressed and explained if it needs to be explained instead of guessed at. Thanks, Steve.
On Sun, 4 Aug 2013, at 06:48 PM, John Maddock wrote:
So I'm inclined to agree to whatever you want ;-) But perhaps more to the point we should be doing whatever our users want - so perhaps it would be better to open up a discussion on boost-users on which compilers we can drop and work from there.
I'll do that this evening.
On 05.08.2013 14:33, Daniel James wrote:
So I'm inclined to agree to whatever you want ;-) But perhaps more to the point we should be doing whatever our users want - so perhaps it would be better to open up a discussion on boost-users on which compilers we can drop and work from there. I'll do that this evening. I don't think that many of the boost users really read the boost-users newsgroup. It would be nice to create a poll at the boost.org site.
-- Sergey Cheban
On Mon, 5 Aug 2013, at 01:29 PM, Sergey Cheban wrote:
On 05.08.2013 14:33, Daniel James wrote:
So I'm inclined to agree to whatever you want ;-) But perhaps more to the point we should be doing whatever our users want - so perhaps it would be better to open up a discussion on boost-users on which compilers we can drop and work from there. I'll do that this evening. I don't think that many of the boost users really read the boost-users newsgroup. It would be nice to create a poll at the boost.org site.
I'll put a request up on the site, but I don't think a poll is appropriate. Will probably just ask for emails from anyone using older compilers. I'm not sure if people check the site either, but I think a few people are subscribed to the news rss feed and a news item can be linked to. If anyone is feeling keen they could set something up. It might be a good idea at some point to do a survey of boost users.
I am a casual Boost user and for my part, I think it is completely okay to drop support for old compilers if it reduces interdependencies in Boost. I'd love for BCP to someday tell me that I need only one or two header-only libraries when I use one library, rather than 8 or 9. If dropping support for older compilers goes some way towards this, I'm all for it. I use VC++ 2010 and GCC 4.7. Kind regards, Philip Bennefall
On 08/05/2013 01:46 PM, Daniel James wrote:
On 05.08.2013 14:33, Daniel James wrote:
So I'm inclined to agree to whatever you want ;-) But perhaps more to the point we should be doing whatever our users want - so perhaps it would be better to open up a discussion on boost-users on which compilers we can drop and work from there. I'll do that this evening. I don't think that many of the boost users really read the boost-users newsgroup. It would be nice to create a poll at the boost.org site. I'll put a request up on the site, but I don't think a poll is appropriate. Will probably just ask for emails from anyone using older compilers. I'm not sure if people check the site either, but I think a few people are subscribed to the news rss feed and a news item can be
On Mon, 5 Aug 2013, at 01:29 PM, Sergey Cheban wrote: linked to.
If anyone is feeling keen they could set something up. It might be a good idea at some point to do a survey of boost users.
What happened to 'users of ancient compilers can use ancient boost' ? Given that boost is quite explicit that it doesn't guarantee source or binary compatibility, http://thread.gmane.org/gmane.comp.lib.boost.devel/237484/focus=237500 http://thread.gmane.org/gmane.comp.lib.boost.devel/237484/focus=237518 I don't see why bumping a compiler requirement from one set of antiques to another slightly more recent set of antiques is an issue that needs to be suspended for a long time with so much red tape as user surveys. Users of ancient compilers can use ancient boost. Given that you have no complaints from anyone using an antique with the recent boost releases, and given that many people in this thread have repeated that many libraries do not work with the antiques and they are not tested anyway, you have a good case to assume that the impact of bumping the requirement is very low. You don't need user surveys. Please just commit the patches today and move on :). Let progress happen and get out of the way :). Thanks, Steve.
on Mon Aug 05 2013, Stephen Kelly <steveire-AT-gmail.com> wrote:
On 08/05/2013 01:46 PM, Daniel James wrote:
On Mon, 5 Aug 2013, at 01:29 PM, Sergey Cheban wrote:
On 05.08.2013 14:33, Daniel James wrote:
So I'm inclined to agree to whatever you want ;-) But perhaps more to
the point we should be doing whatever our users want - so perhaps it would be better to open up a discussion on boost-users on which compilers we can drop and work from there. I'll do that this evening. I don't think that many of the boost users really read the boost-users newsgroup. It would be nice to create a poll at the boost.org site. I'll put a request up on the site, but I don't think a poll is appropriate. Will probably just ask for emails from anyone using older compilers. I'm not sure if people check the site either, but I think a few people are subscribed to the news rss feed and a news item can be linked to.
If anyone is feeling keen they could set something up. It might be a good idea at some point to do a survey of boost users.
What happened to 'users of ancient compilers can use ancient boost' ?
Given that boost is quite explicit that it doesn't guarantee source or binary compatibility,
http://thread.gmane.org/gmane.comp.lib.boost.devel/237484/focus=237500
http://thread.gmane.org/gmane.comp.lib.boost.devel/237484/focus=237518
I don't see why bumping a compiler requirement from one set of antiques to another slightly more recent set of antiques is an issue that needs to be suspended for a long time with so much red tape as user surveys.
+1
Users of ancient compilers can use ancient boost. Given that you have no complaints from anyone using an antique with the recent boost releases, and given that many people in this thread have repeated that many libraries do not work with the antiques and they are not tested anyway, you have a good case to assume that the impact of bumping the requirement is very low.
You don't need user surveys. Please just commit the patches today and move on :). Let progress happen and get out of the way :).
+1 -- Dave Abrahams
On 05.08.2013 18:47, Dave Abrahams wrote:
I don't see why bumping a compiler requirement from one set of antiques to another slightly more recent set of antiques is an issue that needs to be suspended for a long time with so much red tape as user surveys. +1
You don't need user surveys. Please just commit the patches today and move on :). Let progress happen and get out of the way :).
+1
Ok, what about dropping the antique C++03? Do you know the current users' demands? I don't, really. So, I think that it would be interesting to see the survey results anyway. -- Sergey Cheban
On 5 August 2013 20:22, Sergey Cheban wrote:
Ok, what about dropping the antique C++03? Do you know the current users' demands? I don't, really. So, I think that it would be interesting to see the survey results anyway.
C++03 is not an antique, it's one version before the current standard. Noone is suggesting only supporting the current version of compilers.
05.08.2013 23:29, Jonathan Wakely пишет: >> Ok, what about dropping the antique C++03? Do you know the current users' >> demands? I don't, really. So, I think that it would be interesting to see >> the survey results anyway. > C++03 is not an antique, it's one version before the current standard. > Noone is suggesting only supporting the current version of compilers. 1. C++03 is exactly as old as Visual Studio 2003 is. 2. I was not asking you about your opinion. I was asking about your _knowledge_ of user demands. Well, the user demands is not the only reason for the Boost community decisions. But it is important. Other reasons are: - code clearness - ease of development - runtime performance - ability to test the Boost libraries with the compiler PS. What would you say if the survey showed that nobody really needs the C++03 to be supported? I think that such results are possible in the not-so-distant future. -- Best regards, Sergey Cheban
On 5 August 2013 23:19, Sergey Cheban wrote:
05.08.2013 23:29, Jonathan Wakely пишет:
Ok, what about dropping the antique C++03? Do you know the current users' demands? I don't, really. So, I think that it would be interesting to see the survey results anyway.
C++03 is not an antique, it's one version before the current standard. Noone is suggesting only supporting the current version of compilers.
1. C++03 is exactly as old as Visual Studio 2003 is.
What makes age in years the right measurement? C++03 is ten years old but one standard old. VS2003 is 10 years old but something like five versions old. What part of "it's one version before the current standard" wasn't clear?
2. I was not asking you about your opinion. I was asking about your _knowledge_ of user demands.
I already stated it at the top of the thread.
Well, the user demands is not the only reason for the Boost community decisions. But it is important. Other reasons are: - code clearness - ease of development - runtime performance - ability to test the Boost libraries with the compiler
PS. What would you say if the survey showed that nobody really needs the C++03 to be supported? I think that such results are possible in the not-so-distant future.
Then by all means consider removing it, but until you have numbers that's a strawman.
1. C++03 is exactly as old as Visual Studio 2003 is.
C++03 is also as new as VS2010, and to a lesser extend VS2012 which is the current release of VS and still does not support key C++11 language features. The latest version of MinGW (gcc 4.8.1) for Windows also does not support some of the features mandated by C++11 (mainly library features). The defaults for gcc compilers (and I think clang compilers) is also still C++03 (i.e. the user must specify -std=c++11 to get C++11) I don't know what the state of Intel's compiler is. I don't think dropping C++03 support is warranted at this time, though I do think requiring C++03 minimum compatibility would be ok if it already isn't (especially since C++98 is very similar to C++03).
on Mon Aug 05 2013, Sergey Cheban <s.cheban-AT-drweb.com> wrote:
On 05.08.2013 18:47, Dave Abrahams wrote:
I don't see why bumping a compiler requirement from one set of antiques to another slightly more recent set of antiques is an issue that needs to be suspended for a long time with so much red tape as user surveys. +1
You don't need user surveys. Please just commit the patches today and move on :). Let progress happen and get out of the way :).
+1
Ok, what about dropping the antique C++03? Do you know the current users' demands? I don't, really. So, I think that it would be interesting to see the survey results anyway.
Sure, they would be interesting, but IMO the benefits to Boost of making the change immediately outweigh the benefits of doing the survey. -- Dave Abrahams
On Mon, 05 Aug 2013 07:47:24 -0700, Dave Abrahams <dave@boostpro.com> wrote:
on Mon Aug 05 2013, Stephen Kelly <steveire-AT-gmail.com> wrote:
[snip]
I don't see why bumping a compiler requirement from one set of antiques to another slightly more recent set of antiques is an issue that needs to be suspended for a long time with so much red tape as user surveys.
+1
You don't need user surveys. Please just commit the patches today and move on :). Let progress happen and get out of the way :).
+1
-1 I for one commend John and Daniel for soliciting user feedback and proactively engaging the Boost user community before making decisions which may significantly affect them. Mostafa
On Mon, 5 Aug 2013, at 02:12 PM, Stephen Kelly wrote:
On 08/05/2013 01:46 PM, Daniel James wrote:
On 05.08.2013 14:33, Daniel James wrote:
So I'm inclined to agree to whatever you want ;-) But perhaps more to the point we should be doing whatever our users want - so perhaps it would be better to open up a discussion on boost-users on which compilers we can drop and work from there. I'll do that this evening. I don't think that many of the boost users really read the boost-users newsgroup. It would be nice to create a poll at the boost.org site. I'll put a request up on the site, but I don't think a poll is appropriate. Will probably just ask for emails from anyone using older compilers. I'm not sure if people check the site either, but I think a few people are subscribed to the news rss feed and a news item can be
On Mon, 5 Aug 2013, at 01:29 PM, Sergey Cheban wrote: linked to.
If anyone is feeling keen they could set something up. It might be a good idea at some point to do a survey of boost users.
What happened to 'users of ancient compilers can use ancient boost' ?
Nothing. Some people may agree, but it was never accepted as a principle. I don't think it's a reasonable thing to say unless we were to create stable releases and continue to support them.
Given that boost is quite explicit that it doesn't guarantee source or binary compatibility,
That's irrelevant. And just because something isn't guaranteed, it doesn't mean that no one cares.
I don't see why bumping a compiler requirement from one set of antiques to another slightly more recent set of antiques is an issue that needs to be suspended for a long time with so much red tape as user surveys.
It's hardly a bureaucratic nightmare. It will probably require less effort than this thread. I think I have a good idea what the answer will be, but it'd be good to check. The survey was just a vague suggestion for the future ("at some point") that will probably never be picked up, although I do think it'd be helpful. We really don't have enough information about our users.
Users of ancient compilers can use ancient boost. Given that you have no complaints from anyone using an antique with the recent boost releases, and given that many people in this thread have repeated that many libraries do not work with the antiques and they are not tested anyway, you have a good case to assume that the impact of bumping the requirement is very low.
"Many libraries" is not the same as "all libraries".
You don't need user surveys. Please just commit the patches today and move on :). Let progress happen and get out of the way :).
You seem convinced that the change will have no effect, so why do you think people will block it? This is quite a big change, it shouldn't be rushed. Config needs to be conservative about change, perhaps more than any other part of boost.
on Mon Aug 05 2013, Daniel James <daniel-AT-calamity.org.uk> wrote:
On Mon, 5 Aug 2013, at 02:12 PM, Stephen Kelly wrote:
I don't see why bumping a compiler requirement from one set of antiques to another slightly more recent set of antiques is an issue that needs to be suspended for a long time with so much red tape as user surveys.
It's hardly a bureaucratic nightmare. It will probably require less effort than this thread. I think I have a good idea what the answer will be, but it'd be good to check. The survey was just a vague suggestion for the future ("at some point") that will probably never be picked up, although I do think it'd be helpful. We really don't have enough information about our users.
Now I'm really confused. Are you saying we should take a survey right away, before making any such change, or that we should make the change and then do the survey "at some point" in the future, or...? -- Dave Abrahams
On Tue, 6 Aug 2013, at 05:16 AM, Dave Abrahams wrote:
on Mon Aug 05 2013, Daniel James <daniel-AT-calamity.org.uk> wrote:
On Mon, 5 Aug 2013, at 02:12 PM, Stephen Kelly wrote:
I don't see why bumping a compiler requirement from one set of antiques to another slightly more recent set of antiques is an issue that needs to be suspended for a long time with so much red tape as user surveys.
It's hardly a bureaucratic nightmare. It will probably require less effort than this thread. I think I have a good idea what the answer will be, but it'd be good to check. The survey was just a vague suggestion for the future ("at some point") that will probably never be picked up, although I do think it'd be helpful. We really don't have enough information about our users.
Now I'm really confused. Are you saying we should take a survey right away, before making any such change, or that we should make the change and then do the survey "at some point" in the future, or...?
When I said "survey" I didn't mean a single mail to a mailing list, I meant an online survey with several questions (which version of boost do use, how often do you upgrade, which libraries do you use, how big is your code base, do you read the lists, if boost were a horse which breed of horse would it be). That would have to be done over a longer period of time to try to get it seen by as many people as possible.
on Mon Aug 05 2013, Daniel James <daniel-AT-calamity.org.uk> wrote:
On Tue, 6 Aug 2013, at 05:16 AM, Dave Abrahams wrote:
on Mon Aug 05 2013, Daniel James <daniel-AT-calamity.org.uk> wrote:
On Mon, 5 Aug 2013, at 02:12 PM, Stephen Kelly wrote:
I don't see why bumping a compiler requirement from one set of antiques
to another slightly more recent set of antiques is an issue that needs to be suspended for a long time with so much red tape as user surveys.
It's hardly a bureaucratic nightmare. It will probably require less effort than this thread. I think I have a good idea what the answer will be, but it'd be good to check. The survey was just a vague suggestion for the future ("at some point") that will probably never be picked up, although I do think it'd be helpful. We really don't have enough information about our users.
Now I'm really confused. Are you saying we should take a survey right away, before making any such change, or that we should make the change and then do the survey "at some point" in the future, or...?
When I said "survey" I didn't mean a single mail to a mailing list, I meant an online survey with several questions (which version of boost do use, how often do you upgrade, which libraries do you use, how big is your code base, do you read the lists, if boost were a horse which breed of horse would it be). That would have to be done over a longer period of time to try to get it seen by as many people as possible.
OK, makes sense. Apaloosa, BTW. -- Dave Abrahams
On 6 August 2013 07:52, Daniel James wrote:
When I said "survey" I didn't mean a single mail to a mailing list, I meant an online survey with several questions (which version of boost do use, how often do you upgrade, which libraries do you use, how big is your code base, do you read the lists, if boost were a horse which breed of horse would it be). That would have to be done over a longer period of time to try to get it seen by as many people as possible.
Do you mean something hosted on boost.org or is something like surveymonkey good enough? e.g. http://goo.gl/WvzM7V What other compilers or compiler releases should be listed? I didn't include the "how big is your codebase?" question, what type of answers would you want for that?
On Tue, 6 Aug 2013, at 09:01 PM, Jonathan Wakely wrote:
On 6 August 2013 07:52, Daniel James wrote:
When I said "survey" I didn't mean a single mail to a mailing list, I meant an online survey with several questions (which version of boost do use, how often do you upgrade, which libraries do you use, how big is your code base, do you read the lists, if boost were a horse which breed of horse would it be). That would have to be done over a longer period of time to try to get it seen by as many people as possible.
Do you mean something hosted on boost.org or is something like surveymonkey good enough? e.g. http://goo.gl/WvzM7V
What other compilers or compiler releases should be listed? I didn't include the "how big is your codebase?" question, what type of answers would you want for that?
I have no plans. It's just a vague suggestion for the future.
on Sun Aug 04 2013, "John Maddock" <john-AT-johnmaddock.co.uk> wrote:
Do you have an opinion on the original change? The only contentious part of it seems to be dropping Visual C++ 7.0.
Well I'm sort of sitting on the fence ;-)
I suspect from a purely practical perspective, few libraries are still compatible with that compiler, so I'm inclined to agree we might as well drop support. Of course that opens a whole can of worms, because if we agreed to that then there's a whole slew of config macros (and associated workarounds) that can be removed.
So I'm inclined to agree to whatever you want ;-) But perhaps more to the point we should be doing whatever our users want - so perhaps it would be better to open up a discussion on boost-users on which compilers we can drop and work from there. If I have a criticism of this current suggestion it's that the motivation is the wrong way around - in principle we shouldn't be dropping support for something just because it make modularization easier, even if in the end, dropping support for that feature may well be the right thing to do.
Why not? We make decisions all the time about what's worth supporting in order to move Boost forward effectively. -- Dave Abrahams
on Sun Aug 04 2013, Stephen Kelly <steveire-AT-gmail.com> wrote:
On 08/03/2013 11:03 PM, Dave Abrahams wrote:
on Mon Jul 29 2013, Stephen Kelly <steveire-AT-gmail.com> wrote:
My preference is increasing the compiler requirement, because that may open up more similar opportunities for reducing dependencies and interdependencies throughout boost.
Grepping indicates that that means increasing the compiler requirements to something like __DMC__ > 0x840, I'd be shocked if any version of that compiler worked with any substantial fraction of the Boost codebase.
Ok, then the patch I posted which was specific to that compiler should be fine.
GCC > 3.2, BOOST_INTEL_CXX_VERSION > 500, VC++ > 7.0. +1
What do you think about increasing the compiler requirement much more, as I wrote in another mail?
Well, it's not up to me, really. It /might/ be good for Boost, but I would expect consensus to show us the right answer. I don't have a strong personal feeling either way. -- Dave Abrahams
On 07/29/2013 01:17 PM, Stephen Kelly wrote:
Grepping indicates that that means increasing the compiler requirements to something like __DMC__ > 0x840, GCC > 3.2, BOOST_INTEL_CXX_VERSION > 500, VC++ > 7.0.
What about the Borland C++ compiler (from before it became CodeGear). AFAIK, it is not in widespread use today, yet it is responsible for several ugly hacks in the codebase.
On 08/04/2013 01:59 PM, Bjorn Reese wrote:
On 07/29/2013 01:17 PM, Stephen Kelly wrote:
Grepping indicates that that means increasing the compiler requirements to something like __DMC__ > 0x840, GCC > 3.2, BOOST_INTEL_CXX_VERSION > 500, VC++ > 7.0.
What about the Borland C++ compiler (from before it became CodeGear). AFAIK, it is not in widespread use today, yet it is responsible for several ugly hacks in the codebase.
Assuming you are referring to what you quoted: What you quoted relates to the use of the BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS macro. Thanks, Steve.
On 08/04/2013 01:59 PM, Bjorn Reese wrote:
On 07/29/2013 01:17 PM, Stephen Kelly wrote:
Grepping indicates that that means increasing the compiler requirements to something like __DMC__ > 0x840, GCC > 3.2, BOOST_INTEL_CXX_VERSION > 500, VC++ > 7.0.
What about the Borland C++ compiler (from before it became CodeGear). AFAIK, it is not in widespread use today, yet it is responsible for several ugly hacks in the codebase.
Assuming you are thinking about minimum compiler versions in general: That's the spirit! Thanks, Steve.
On 08/04/2013 02:21 PM, Stephen Kelly wrote:
On 08/04/2013 01:59 PM, Bjorn Reese wrote:
On 07/29/2013 01:17 PM, Stephen Kelly wrote:
Grepping indicates that that means increasing the compiler requirements to something like __DMC__ > 0x840, GCC > 3.2, BOOST_INTEL_CXX_VERSION > 500, VC++ > 7.0.
What about the Borland C++ compiler (from before it became CodeGear). AFAIK, it is not in widespread use today, yet it is responsible for several ugly hacks in the codebase.
Assuming you are thinking about minimum compiler versions in general: That's the spirit!
Yes.
On 07/29/2013 01:17 PM, Stephen Kelly wrote:
My preference is increasing the compiler requirement, because that may open up more similar opportunities for reducing dependencies and interdependencies throughout boost.
Hello, What is the status of this? http://thread.gmane.org/gmane.comp.lib.boost.devel/243094 There is obviously no more I can do. I can't convince the boost community to modularize if you don't want to. I don't think the thread came to any definitive conclusion though and my patch didn't get committed. Should I draw a conclusion that nothing is ever going to happen? Thanks, Steve.
On 09/12/2013 04:59 PM, Stephen Kelly wrote:
What is the status of this?
Bjorn Reese wrote:
On 09/12/2013 04:59 PM, Stephen Kelly wrote:
What is the status of this?
Oh, thanks! And thanks Daniel for committing the patches. I made a mistake thinking that the patches were not committed yet. I'll send more patches soon to clear up some stuff in obsolete ifdefs. Thanks, Steve
participants (15)
-
Andrew Ho -
Bjorn Reese -
Bo Persson -
Daniel James -
Dave Abrahams -
Edward Diener -
John Maddock -
Jonathan Wakely -
Marshall Clow -
Mostafa -
Paul A. Bristow -
Philip Bennefall -
Rob Stewart -
Sergey Cheban -
Stephen Kelly