Compliance with Boost copyright and license guidelines
Prompted by some recent discussion of Boost license and copyright info by the Debian package team, I have recently been checking on the Boost.Multiprecision library and run the Boost inspect program https://www.boost.org/doc/libs/1_70_0/tools/inspect/ (originally written by Beman Dawes in 2003 and revised several times since). I’ve made some minor cosmetic changes to the program and the rather sparse documentation to make it easier to use by library authors and give a bit more info. It checks on compliance with https://www.boost.org/development/requirements.html. It’s use has been a little neglected recently but I conclude that we are not doing well enough in providing the proof of copyright and license that we promise. The results of my run of inspect on the boost/lib folder using develop branch are not pretty Problem counts: 1790 files missing Boost license info or having wrong reference text 1682 files missing copyright notice (but not I suspect quite as bad as they look – some items probably do not need copyright and license). Now that the 1.71 release is out bar a little shouting, I wonder if we should focus on improving compliance for the next release? I’d like to propose 1 A boost/tools/inspect/develop branch to refine the inspect program a little and improve the documentation (I have done something on this already for my education and use). 2 Discussion of the bad results (zip attached) to try to find why there are so many reports and to decide what to do. 3 Encourage all authors to run inspect on their library locally and try to remedy the items missing. 4 I suspect that many libraries will have items missing but the authors are also missing. So someone from the community maintenance team will need to take over and make some decisions on what to do. Often just providing a copyright claim from the obvious author and Boost license will suffice? 5 Try to improve the compliance with other guidelines. For example. there are many libraries that are failing to prevent with min and max macros for what of a couple of brackets. Usually (std::numeric_limits<>::max)(). All these will trip up Windows users in a puzzling way. Please can we just fix these? Views? Paul PS My halo is shining brightly 😉 Boost.Multiprecision has a problem count of zero 😊 (and I’m working on Boost.Math) Boost Inspection Report Inspect version no 3.1.15 Run Date: 08:44:19 UTC, Saturday 17 August 2019 Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) Copyright Boost 2019 boost-no-inspect Inspection from path "libs" including subfolders. Totals: 52355 files scanned 4351 directories scanned (including root) 3472 problems reported Problem counts: 1790 files missing Boost license info or having wrong reference text 1682 files missing copyright notice Worst Offenders: outcome 940 metaparse 556 polygon 228 python 194 beast 192 Summary: algorithm (4) array (2) asio (12) … Paul A. Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK
On Sun, 18 Aug 2019, 18:55 Paul A Bristow via Boost, <boost@lists.boost.org> wrote:
Prompted by some recent discussion of Boost license and copyright info by the Debian package team,
[...]
Now that the 1.71 release is out bar a little shouting, I wonder if we should focus on improving compliance for the next release?
I’d like to propose
1 A boost/tools/inspect/develop branch to refine the inspect program a little and improve the documentation (I have done something on this already for my education and use).
2 Discussion of the bad results (zip attached) to try to find why there are so many reports and to decide what to do.
3 Encourage all authors to run inspect on their library locally and try to remedy the items missing.
4 I suspect that many libraries will have items missing but the authors are also missing. So someone from the community maintenance team will need to take over and make some decisions on what to do. Often just providing a copyright claim from the obvious author and Boost license will suffice?
5 Try to improve the compliance with other guidelines. For example. there are many libraries that are failing to prevent with min and max macros for what of a couple of brackets. Usually (std::numeric_limits<>::max)(). All these will trip up Windows users in a puzzling way. Please can we just fix these?
+1 Boost Inspection Report
Inspect version no 3.1.15 Run Date: 08:44:19 UTC, Saturday 17 August 2019 Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) Copyright Boost 2019
boost-no-inspect Inspection from path "libs" including subfolders. Totals: 52355 files scanned 4351 directories scanned (including root) 3472 problems reported
Problem counts: 1790 files missing Boost license info or having wrong reference text 1682 files missing copyright notice
Worst Offenders: outcome 940 metaparse 556 polygon 228 python 194 beast 192
Summary: algorithm (4) array (2)
FYI, I made an attempt a while ago to fix the array: https://github.com/boostorg/array/pull/9 -- Mateusz Loskot, mateusz@loskot.net (Sent from mobile, may suffer from top-posting)
I fully support Paul's initiative to fix the copyright issues for the next release.
On 18. Aug 2019, at 18:54, Paul A Bristow via Boost <boost@lists.boost.org> wrote:
1 A boost/tools/inspect/develop branch to refine the inspect program a little and improve the documentation (I have done something on this already for my education and use).
I think this program should be rewritten in Python which would simplify maintaining and using it (no compilation needed, simpler code, Python's string processing is fast enough).
3 Encourage all authors to run inspect on their library locally and try to remedy the items missing.
I started to fix some copyright messages in Boost.Histogram, but there is still more to do.
4 I suspect that many libraries will have items missing but the authors are also missing. So someone from the community maintenance team will need to take over and make some decisions on what to do. Often just providing a copyright claim from the obvious author and Boost license will suffice?
Sounds reasonable. In any case, we can already make a lot of progress by fixing all the libraries with have active maintainers and then worry about the others.
5 Try to improve the compliance with other guidelines. For example. there are many libraries that are failing to prevent with min and max macros for what of a couple of brackets. Usually (std::numeric_limits<>::max)(). All these will trip up Windows users in a puzzling way. Please can we just fix these?
The page http://boost.cowic.de/rc/docs-inspect-develop.html should link to the guideline that is violated, https://www.boost.org/development/requirements.html. I didn't understand what was meant at first.
Views?
- For things like the min/max guideline, a tool that is clever enough to correctly find these issues could also just apply the fix directly in the code. The inspect tool could have a command line option to apply fixes as well or at least suggest the fixed code line. - To give the inspection report more visibility, there should be an entry in the menu of www.boost.org. Under "Development" we currently have "Master Summary" and "Master Issues". There should also be "Master Inspection Report". And vice versa for "Development *". Best regards, Hans
On Mon, Aug 19, 2019 at 2:57 AM Hans Dembinski via Boost < boost@lists.boost.org> wrote:
I fully support Paul's initiative to fix the copyright issues for the next release.
On 18. Aug 2019, at 18:54, Paul A Bristow via Boost < boost@lists.boost.org> wrote:
1 A boost/tools/inspect/develop branch to refine the inspect program a little and improve the documentation (I have done something on this already for my education and use).
I think this program should be rewritten in Python which would simplify maintaining and using it (no compilation needed, simpler code, Python's string processing is fast enough).
- To give the inspection report more visibility, there should be an entry in the menu of www.boost.org. Under "Development" we currently have "Master Summary" and "Master Issues". There should also be "Master Inspection Report". And vice versa for "Development *".
It would be fantastic to see a PR for the existing library check Python program < https://github.com/boostorg/boost/blob/develop/status/boost_check_library.py>. as that would achieve the goal of providing continuous visibility on a per branch and per library basis as you suggest. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net
On 19.08.19 17:45, Rene Rivera via Boost wrote:
On Mon, Aug 19, 2019 at 2:57 AM Hans Dembinski via Boost < boost@lists.boost.org> wrote:
[snip]
It would be fantastic to see a PR for the existing library check Python program < https://github.com/boostorg/boost/blob/develop/status/boost_check_library.py>. as that would achieve the goal of providing continuous visibility on a per branch and per library basis as you suggest.
Do you want to run inspect using this python script or do you want a full implementation of inspect in python?
On Tue, Aug 20, 2019 at 2:35 PM Raffi Enficiaud via Boost < boost@lists.boost.org> wrote:
On 19.08.19 17:45, Rene Rivera via Boost wrote:
On Mon, Aug 19, 2019 at 2:57 AM Hans Dembinski via Boost < boost@lists.boost.org> wrote:
[snip]
It would be fantastic to see a PR for the existing library check Python program <
. as that would achieve the goal of providing continuous visibility on a
https://github.com/boostorg/boost/blob/develop/status/boost_check_library.py per
branch and per library basis as you suggest.
Do you want to run inspect using this python script or do you want a full implementation of inspect in python?
We can start with the license checks. And eventually add more inspect functionality if needed. But the goal is not to run the inspect program itself preferring to "port" the functionality over. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net
On 20. Aug 2019, at 21:40, Rene Rivera via Boost <boost@lists.boost.org> wrote:
On Tue, Aug 20, 2019 at 2:35 PM Raffi Enficiaud via Boost < boost@lists.boost.org> wrote:
On 19.08.19 17:45, Rene Rivera via Boost wrote:
On Mon, Aug 19, 2019 at 2:57 AM Hans Dembinski via Boost < boost@lists.boost.org> wrote:
[snip]
It would be fantastic to see a PR for the existing library check Python program <
. as that would achieve the goal of providing continuous visibility on a
https://github.com/boostorg/boost/blob/develop/status/boost_check_library.py per
branch and per library basis as you suggest.
Do you want to run inspect using this python script or do you want a full implementation of inspect in python?
We can start with the license checks. And eventually add more inspect functionality if needed. But the goal is not to run the inspect program itself preferring to "port" the functionality over.
Great, I would like to give it a shot. I am a senior Python developer. Just running `python status/boost_check_library.py` locally gives an error instead of a helpful usage message. I will work on improving that as well. Best regards, Hans
On 20. Aug 2019, at 21:40, Rene Rivera via Boost <boost@lists.boost.org> wrote:
On Tue, Aug 20, 2019 at 2:35 PM Raffi Enficiaud via Boost < boost@lists.boost.org> wrote:
On 19.08.19 17:45, Rene Rivera via Boost wrote:
On Mon, Aug 19, 2019 at 2:57 AM Hans Dembinski via Boost < boost@lists.boost.org> wrote:
[snip]
It would be fantastic to see a PR for the existing library check Python program <
. as that would achieve the goal of providing continuous visibility on a
https://github.com/boostorg/boost/blob/develop/status/boost_check_library.py per
branch and per library basis as you suggest.
Do you want to run inspect using this python script or do you want a full implementation of inspect in python?
We can start with the license checks. And eventually add more inspect functionality if needed. But the goal is not to run the inspect program itself preferring to "port" the functionality over.
What is the minimum Python version that has to be supported? Python 2.7?
What is the minimum Python version that has to be supported? Python 2.7?
Python 2 is almost EOL. As this is a dev-tool primarily targeted at library developers, there should be no reason to maintain Python 2 support. Python 3 is even older than c++11 which is IIRC required by b2. Is there a list somewhere, which files don't require a license header (e.g. .gitignore) Best Mike
On 21. Aug 2019, at 10:25, Mike via Boost <boost@lists.boost.org> wrote:
What is the minimum Python version that has to be supported? Python 2.7?
Python 2 is almost EOL. As this is a dev-tool primarily targeted at library developers, there should be no reason to maintain Python 2 support. Python 3 is even older than c++11 which is IIRC required by b2.
I agree with you, but boost_check_library.py has to work on all the machines which run the Boost Test matrix, therefore the script has to be compatible with the Python versions on these machines. If all of them have Python3 already, great. I am mainly asking because I would like to replace optparse with argparse, which first appeared in Python2.7.
-----Original Message----- From: Boost <boost-bounces@lists.boost.org> On Behalf Of Mike via Boost Sent: 21 August 2019 09:25 To: boost@lists.boost.org Cc: Mike <mike.dev@gmx.de> Subject: [boost] Compliance with Boost copyright and license guidelines
What is the minimum Python version that has to be supported? Python 2.7?
Python 2 is almost EOL. As this is a dev-tool primarily targeted at library developers, there should be no reason to maintain Python 2 support. Python 3 is even older than c++11 which is IIRC required by b2.
Is there a list somewhere, which files don't require a license header (e.g. .gitignore)
https://www.boost.org/doc/libs/1_71_0/tools/inspect/inspect.cpp but in description in my revised docs: "File types that are inspected: C/C++ source code... ".c" ".cpp" ".css" ".cxx" ".h" ".hpp" ".hxx" ".inc" ".ipp" Boost.Build BJam source code... "Jamfile" ".jam" ".v2" Other scripts; Python, shell, autoconfig, etc. "configure.in"; "GNUmakefile" "Makefile" ".bat" ".mak" ".pl" ".py" ".sh" Hypertext, Boost.Book, and other text... "news" "readme" "todo" "NEWS" "README" "TODO" ".boostbook" ".htm" ".html" ".rst" ".sgml" ".shtml" ".txt" ".xml" ".xsd" ".xsl" ".qbk" ".htm" ".html" ".shtml" But files that are NOT inspected are: Files that contain boost-no-inspect. Files in a folder called boost-no-inspect. Files of type doc/xml re not checked as they may be Doxygen output. Files of type .bin. (Generated executable files are not required to contain license and copyright. Folder bin.v2 that contain Boost b2/bjam working sub-folders and files." Also Folders whose name is prefixed by a dot "." like `.git`. This gives scope for authors (or others) to decide themselves what can be excluded from inspection by adding "boost-no-inspect". This means that the inspection program inspect.py itself should have a copyright and license claim 😉 HTH Paul PS I'm willing to accept that Python is a low bar (though it is yet another widget to install for Microsoftys). But it's got to work 😉 Paul A. Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK
On Wed, 21 Aug 2019 at 17:22, Paul A Bristow via Boost < boost@lists.boost.org> wrote:
PS I'm willing to accept that Python is a low bar (though it is yet another widget to install for Microsoftys). But it's got to work 😉
The python installation process is at least a lot easier than to install Boost, and it [the installer] does what we dummies softies are used to: download, run installer, click yes until it stops nagging and then wait. We softies handle that relatively well, as that's the process with all [the majority at least] installs. We are blissfully unaware of dependencies or crt's, though. Ah wait, that [to have awareness] is not necessary by design. Ah well. degski -- @realdegski https://edition.cnn.com/interactive/2019/06/middleeast/saudi-teen-death-pena... "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey
-----Original Message----- From: Boost <boost-bounces@lists.boost.org> On Behalf Of degski via Boost Sent: 22 August 2019 04:53 To: boost <boost@lists.boost.org> Cc: degski <degski@gmail.com> Subject: Re: [boost] Compliance with Boost copyright and license guidelines
On Wed, 21 Aug 2019 at 17:22, Paul A Bristow via Boost < boost@lists.boost.org> wrote:
PS I'm willing to accept that Python is a low bar (though it is yet another widget to install for Microsoftys). But it's got to work 😉
The python installation process is at least a lot easier than to install Boost, and it [the installer] does what we dummies softies are used to:
I was implying that the *son-of-inspect* Python program has got to work. The current inspect has worked for nearly two decades and still does. And John Maddock has just made the CI process run it routinely, so people can see how bad their library is much more easily. With Multiprecision and Math libraries, it is just the tedious process of checking all the inspect reports and deciding what to do about them. Lots of errant, tax, max/min macro issues, missing licences (many live generated files that we could manage without licences, though a tip to people writing C++ or other code to generate C++ code, it is easy at the writing stage to code to write the license and copyright at the head of the generated file (but a hassle and possibly troublesome to do it later, especially for some other poor sucker 😉) Lots of files that don't need license and copyright can have boost-no-inspect written into them, or added, or whole folders made no-inspect. It just needs some work. The big job is sorting out all the libraries, IMO. Paul Paul A. Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK
On 22. Aug 2019, at 09:54, Paul A Bristow via Boost <boost@lists.boost.org> wrote:
I was implying that the *son-of-inspect* Python program has got to work.
The current inspect has worked for nearly two decades and still does.
And John Maddock has just made the CI process run it routinely, so people can see how bad their library is much more easily.
With Multiprecision and Math libraries, it is just the tedious process of checking all the inspect reports and deciding what to do about them.
Lots of errant, tax, max/min macro issues, missing licences (many live generated files that we could manage without licences, though a tip to people writing C++ or other code to generate C++ code, it is easy at the writing stage to code to write the license and copyright at the head of the generated file (but a hassle and possibly troublesome to do it later, especially for some other poor sucker 😉)
The max/min macro issue does not seem to be relevant anymore in modern compilers. I was completely unaware of this in Boost.Histogram and the code works fine on all msvc versions which support C++14. I added the patches to Histogram to get rid of this warning, but now that code became a lot less readable. I am considering to revert this change and propose instead to remove the min/max macro check from the inspection list. Or is there a way to blacklist it locally for my library?
Lots of files that don't need license and copyright can have boost-no-inspect written into them, or added, or whole folders made no-inspect. It just needs some work.
1) A constructive criticism of boost-no-inspect files I worry about using these boost-no-inspect files to prevent scans for whole folders. I think the files themselves are distracting, but moreover, I think it shouldn't be necessary to ignore whole folders. Instead of fixing the copyright notices in my files in Boost.Histogram, I could just have put boost-no-inspect files in the directories. This wouldn't solve the issue that the inspect tool tries to address. boost/status has a boost-no-inspect file, for example, but I think it should not. Like you pointed out, boost_check_library.py should have a license notice, and likewise the xml and xsd files in that folder. I am not a lawyer, but in my understanding - and I can only understand simple consistent rules - everything in Boost which is not automatically generated by another program is by definition "source code", which then needs a license notice. I think the boost-no-inspect files should not be needed, because the directory structure of Boost is very uniform in all projects and this is enforced. It should be predictable for the inspect tool which directories need to be scanned. I think the inspect tool has a good rule set for this, but it should definitely also ignore also what's in .gitignore, see next item. 2) Proposal: parse .gitignore and meta/inspect-ignore The inspect tool gives a lot of false positives when I run it locally on my computer. These would disappear if it would ignore what is in .gitignore. Once this feature is added, we could generally switch to a solution where the inspect tool scans the meta folder and reads a inspect-ignore file. This would have the same format as .gitignore, so the same code in the inspect tool can be used to read both. This would be a better solution than using boost-no-inspect files and "boost-no-inspect" comments. I just posted these suggestions/requests as issues to the boostorg/inspect repo. Summary: I understand that the C++ inspect tool has worked for a long time and it obviously works very well, but software needs to adapt to new demands. We face the decision to either add new features to inspect or to ported the functionality piece by piece over to boost_check_library.py, add then add new features to that version. I think Python is better suited for this sort of task, so you know my view. Best regards, Hans
Gesendet: Donnerstag, 22. August 2019 um 11:06 Uhr Von: "Hans Dembinski via Boost" <boost@lists.boost.org> The max/min macro issue does not seem to be relevant anymore in modern compilers. I was completely unaware of this in Boost.Histogram and the code works fine on all msvc versions which support C++14. I added the patches to Histogram to get rid of this warning, but now that code became a lot less readable. I am considering to revert this change and propose instead to remove the min/max macro check from the inspection list. Or is there a way to blacklist it locally for my library?
This is not a compiler problem. The windows.h file (https://en.wikipedia.org/wiki/Windows.h) is defining those macros unless special workarounds are applied like defining NOMINMAX before including the file. Best Mike
-----Original Message----- From: Boost <boost-bounces@lists.boost.org> On Behalf Of Mike via Boost Sent: 22 August 2019 10:17 To: boost@lists.boost.org Cc: Mike <mike.dev@gmx.de> Subject: Re: [boost] Compliance with Boost copyright and license guidelines
Gesendet: Donnerstag, 22. August 2019 um 11:06 Uhr Von: "Hans Dembinski via Boost" <boost@lists.boost.org> The max/min macro issue does not seem to be relevant anymore in modern compilers. I was completely unaware of this in Boost.Histogram and the code works fine on all msvc versions which support C++14. I added the patches to Histogram to get rid of this warning, but now that code became a lot less readable. I am considering to revert this change and propose instead to remove the min/max macro check from the inspection list. Or is there a way to blacklist it locally for my library?
This is not a compiler problem. The windows.h file (https://en.wikipedia.org/wiki/Windows.h) is defining those macros unless special workarounds are applied like defining NOMINMAX before including the file.
But it is a problem for all those who *use* Boost code *and* Windows - and that is a LOT of people, most perhaps. So there is a longstanding Boost policy that we avoid annoying Windows users. It's a minor nuisance and trivial ugliness in Boost code, adding brackets to (std::max) and (std::numeric_limits<>::max)() etc. Paul PS I suspect that it seemed very cool of Microsoft to define these min and max macros, probably about 30 ago, perhaps even by Bill himself? Paul A. Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK
On Thu, 22 Aug 2019 at 12:52, Paul A Bristow via Boost < boost@lists.boost.org> wrote:
So there is a longstanding Boost policy that we avoid annoying Windows users.
So the fact that Windows.h defines max/min macros, unless guarded by NOMINMAX, makes Windows **users** annoying? Brexit seems to have gone to your head, better get it checked out. degski -- @realdegski https://edition.cnn.com/interactive/2019/06/middleeast/saudi-teen-death-pena... "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey
degski wrote:
So there is a longstanding Boost policy that we avoid annoying Windows users.
So the fact that Windows.h defines max/min macros, unless guarded by NOMINMAX, makes Windows **users** annoying?
avoid - annoying - Windows users not avoid - annoying Windows users That is, we try to avoid making Windows users annoyed.
On Thu, 22 Aug 2019 at 15:37, Peter Dimov via Boost <boost@lists.boost.org> wrote:
degski wrote:
So there is a longstanding Boost policy that we avoid annoying Windows users.
So the fact that Windows.h defines max/min macros, unless guarded by NOMINMAX, makes Windows **users** annoying?
avoid - annoying - Windows users
Better: ... avoid to annoy Windows users. English does have its pitfalls. Thanks for pointing that out. degski -- @realdegski https://edition.cnn.com/interactive/2019/06/middleeast/saudi-teen-death-pena... "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey
On 23/08/2019 00:48, degski wrote:
avoid - annoying - Windows users
Better: ... avoid to annoy Windows users. English does have its pitfalls. Thanks for pointing that out.
That's not really better, since it's grammatically incorrect. You could say "avoid being an annoyance to Windows users". Or use a less ambiguous word "avoid upsetting Windows users". (Which technically could still be read the wrong way, but I don't think anyone would read it that way.)
That's how we get topics of important discussion threads dissolved, decisions not made, actions not taken. It's annoying to be frequently spammed by such off topic digressions. Mateusz Loskot, mateusz@loskot.net (Sent from mobile, may suffer from top-posting) On Fri, 23 Aug 2019, 01:21 Gavin Lambert via Boost, <boost@lists.boost.org> wrote:
On 23/08/2019 00:48, degski wrote:
avoid - annoying - Windows users
Better: ... avoid to annoy Windows users. English does have its pitfalls. Thanks for pointing that out.
That's not really better, since it's grammatically incorrect.
You could say "avoid being an annoyance to Windows users".
Or use a less ambiguous word "avoid upsetting Windows users". (Which technically could still be read the wrong way, but I don't think anyone would read it that way.)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-----Original Message----- From: Boost <boost-bounces@lists.boost.org> On Behalf Of degski via Boost Sent: 22 August 2019 13:29 To: boost <boost@lists.boost.org> Cc: degski <degski@gmail.com> Subject: Re: [boost] Compliance with Boost copyright and license guidelines
On Thu, 22 Aug 2019 at 12:52, Paul A Bristow via Boost < boost@lists.boost.org> wrote:
So there is a longstanding Boost policy that we avoid annoying Windows users.
So the fact that Windows.h defines max/min macros, unless guarded by NOMINMAX, makes Windows **users** annoying? Brexit seems to have gone to your head, better get it checked out.
I'm getting really annoyingly annoyed by this thread 😉 But everyone is annoyed and annoying - by max/min macros - and by Brexit. Paul Paul A. Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK
Hans wrote:
The max/min macro issue does not seem to be relevant anymore in modern compilers. I was completely unaware of this in Boost.Histogram and the code works fine on all msvc versions which support C++14. I added the patches to Histogram to get rid of this warning, but now that code became a lot less readable.
In September 2018, I introduced a use of std::numeric_limits<T>::max() in Boost.CircularBuffer. In November 2018, I received the first of two complaints (from Windows users) so I addressed it. I'm not convinced that it is not relevant anymore. Granted, that was November 2018, and it is now August 2019. Many things have happened since then. For example, as one user has pointed out on this thread, perhaps Brexit has happened. It is entirely possible that Brexit has caused this to no longer be a problem for Windows developers. Glen
On Thu, 22 Aug 2019 at 16:51, Glen Fernandes via Boost < boost@lists.boost.org> wrote:
Granted, that was November 2018, and it is now August 2019. Many things have happened since then.
Don't count on it [having changed]. For example, as one user has pointed out on this thread, perhaps
Brexit has happened.
The Brits keep on postponing it [cos they can't agree on anything], so no, it did not happen, it probably won't, that's my guess. But heck, maybe Trump could buy the UK of the EU, as he seems to be in the mood for buying an island. degski -- @realdegski https://edition.cnn.com/interactive/2019/06/middleeast/saudi-teen-death-pena... "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey
Degski Via Boost wrote:
The Brits keep on postponing it [cos they can't agree on anything], so no, it did not happen, it probably won't, that's my guess. But heck, maybe Trump could buy the UK of the EU, as he seems to be in the mood for buying an island. Unless you're talking about "future islands" I consider this off-topic and discourage you from posting such things.
Adam
On 22. Aug 2019, at 15:51, Glen Fernandes <glen.fernandes@gmail.com> wrote:
Hans wrote:
The max/min macro issue does not seem to be relevant anymore in modern compilers. I was completely unaware of this in Boost.Histogram and the code works fine on all msvc versions which support C++14. I added the patches to Histogram to get rid of this warning, but now that code became a lot less readable.
In September 2018, I introduced a use of std::numeric_limits<T>::max() in Boost.CircularBuffer. In November 2018, I received the first of two complaints (from Windows users) so I addressed it.
I'm not convinced that it is not relevant anymore.
Granted, that was November 2018, and it is now August 2019. Many things have happened since then.
For example, as one user has pointed out on this thread, perhaps Brexit has happened.
It is entirely possible that Brexit has caused this to no longer be a problem for Windows developers.
Ok, I stand corrected. This is still an issue and I didn't really understood where the issue is coming from. Thanks to Glen, Paul, and Mike Dev for explaining.
-----Original Message----- From: Boost <boost-bounces@lists.boost.org> On Behalf Of degski via Boost Sent: 22 August 2019 04:53 To: boost <boost@lists.boost.org> Cc: degski <degski@gmail.com> Subject: Re: [boost] Compliance with Boost copyright and license guidelines
On Wed, 21 Aug 2019 at 17:22, Paul A Bristow via Boost < boost@lists.boost.org> wrote:
PS I'm willing to accept that Python is a low bar (though it is yet another widget to install for Microsoftys). But it's got to work 😉
The python installation process is at least a lot easier than to install Boost
https://devblogs.microsoft.com/python/python-in-the-windows-10-may-2019-upda... It's even easier than I thought - I idly open a dosbox and typed Python and lo this came up. Microsoft Windows [Version 10.0.18362.295] (c) 2019 Microsoft Corporation. All rights reserved. C:\Users\Paul>python Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:59:51) [MSC v.1914 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information.
So no excuse here. But I am still concerned that we are reinventing the wheel here. What is really lacking from the original inspect program? (I think it is documentation - `what to do' in particular and I'm making progress with improving that). Paul Paul A. Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK
Copying my response here as I accidentally sent my original response only to Hans directly:
I agree with you, but boost_check_library.py has to work on all the machines which run the Boost Test matrix,
Does it? Isn't that just a waste of time? IIRC, the script doesn't run unit tests or anything. It just checks for the presence and content of various files and directories. I don't know, why this has to run on every test machine.
I am mainly asking because I would like to replace optparse with argparse, which first appeared in Python2.7.
My opinion: Go ahead. If this causes trouble on a test machine, that is imho a reason to either fix the test machine or to not run the script on that machine (just as unit-tests for c++14 libs are not/should not be run on machines without a c++14 compiler). It should not hold back development. But I guess Rene or maybe Michael are the ones who could give a more authoritative answer on that.
Von: "Paul A Bristow via Boost" <boost@lists.boost.org>
[..]
It's even easier than I thought - I idly open a dosbox and typed Python and lo this came up.
What's a dosbox? I guess you didn't mean https://www.dosbox.com/ ? ;) Sorry, couldn't resist - I.e. I hope, no one is developing boost on a Windows 98/ME system anymore. But I don't have any preference on how those checks are done. Python tends to be suited way better for text processing than c++, but if the code is already there, then I agree - hwy reinvent the wheel. Anyway, if the problems don't get fixed, it doesn't matter what tool is used to detect them. Best Mike
On 22/08/2019 04:52, degski via Boost wrote:
On Wed, 21 Aug 2019 at 17:22, Paul A Bristow via Boost < boost@lists.boost.org> wrote:
PS I'm willing to accept that Python is a low bar (though it is yet another widget to install for Microsoftys). But it's got to work 😉
The python installation process is at least a lot easier than to install Boost, and it [the installer] does what we dummies softies are used to: download, run installer, click yes until it stops nagging and then wait. We softies handle that relatively well, as that's the process with all [the majority at least] installs. We are blissfully unaware of dependencies or crt's, though. Ah wait, that [to have awareness] is not necessary by design. Ah well.
True, but you're going to need (most of) boost anyway. I've just put up a circle-ci job for Boost.Config that runs the current inspect program over the library. It also re-builds the docs first, so I get a check that documentation change PR's will a) build and b) won't cause inspect regressions. It runs really quick too - total time including downloading prerequisites is about 5 minutes. See https://circleci.com/gh/boostorg/config/12 And the yml is here: https://github.com/boostorg/config/blob/develop/.circleci/config.yml Of course if the python version is in some way better, I'll happily just switch over. John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Wed, 21 Aug 2019 at 11:14, Hans Dembinski via Boost < boost@lists.boost.org> wrote:
What is the minimum Python version that has to be supported? Python 2.7?
Python 2 is on its way out, Fedora 31, f.e. will NOT have Python-2.7 by default anymore. degski -- @realdegski https://edition.cnn.com/interactive/2019/06/middleeast/saudi-teen-death-pena... "Anyone who believes that exponential growth can go on forever in a finite world is either a madman or an economist" - Kenneth E. Boulding "Growth for the sake of growth is the ideology of the cancer cell" - Edward P. Abbey
-----Original Message----- From: Boost <boost-bounces@lists.boost.org> On Behalf Of Raffi Enficiaud via Boost Sent: 20 August 2019 20:35 To: boost@lists.boost.org Cc: Raffi Enficiaud <raffi.enficiaud@mines-paris.org> Subject: Re: [boost] Compliance with Boost copyright and license guidelines
On 19.08.19 17:45, Rene Rivera via Boost wrote:
On Mon, Aug 19, 2019 at 2:57 AM Hans Dembinski via Boost < boost@lists.boost.org> wrote:
[snip]
It would be fantastic to see a PR for the existing library check Python program <
https://github.com/boostorg/boost/blob/develop/status/boost_check_library.py
. as that would achieve the goal of providing continuous visibility on a per branch and per library basis as you suggest.
Do you want to run inspect using this python script or do you want a full implementation of inspect in python?
Won't requiring Python put off some library authors from applying a run the inspect program to their own code? (Having the Python program will be valuable for providing an externally visible and usable list). My experience is that one needs to work through ones library fixing each issue and re-running the inspect program - and re-running ones examples and tests to make sure one hasn't screwed up 😉 Waiting for the CI system to catch up with that is intolerably slow. I think that clearing the compliance hurdle only requires some tweaks to the existing inspect program - and some improvements in documentation telling exactly how to run locally, and what to do to be compliant. Paul Paul A. Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK
Won't requiring Python put off some library authors from applying a run the inspect program to their own code?
(Having the Python program will be valuable for providing an externally visible and usable list). I rather see it the other way round: Using and maintaining the Python
Waiting for the CI system to catch up with that is intolerably slow. +1 The static checker which can be run without any setup locally would
Am 21.08.19 um 09:32 schrieb Paul A Bristow via Boost: program will be much easier and faster: Just run it, done. Most devs are likely using Linux anway where Python is preinstalled. Better than having to compile something first, probably need to change it due to false positives and compile again. Then compile own code etc. therefore be a huge bonus.
On 21. Aug 2019, at 09:43, Alexander Grund via Boost <boost@lists.boost.org> wrote:
Am 21.08.19 um 09:32 schrieb Paul A Bristow via Boost:
Won't requiring Python put off some library authors from applying a run the inspect program to their own code?
(Having the Python program will be valuable for providing an externally visible and usable list). I rather see it the other way round: Using and maintaining the Python program will be much easier and faster: Just run it, done. Most devs are likely using Linux anway where Python is preinstalled. Better than having to compile something first, probably need to change it due to false positives and compile again. Then compile own code etc.
+1 I was just about to write the same thing. All notable Linux distribution and OSX comes with pre-installed Python. Only Windows does not ship with Python preinstalled. The threshold to install Python is incredibly low. And it is already used elsewhere, in tools/boostdep/depinst.py
All notable Linux distribution and OSX comes with pre-installed Python. Only Windows does not ship with Python preinstalled.
That got a lot better in the most recent Windows 10 update: https://devblogs.microsoft.com/python/python-in-the-windows-10-may-2019-upda... tldr; python now has a stub executable which takes you to the store install page. Same as the "bash" stub executable, and soon also "wordpad" and "paint". Niall
Paul A Bristow wrote:
3 Encourage all authors to run inspect on their library locally and try to remedy the items missing.
FWIW, the Boost.Timer test Jamfile contains an entry that runs `inspect`: https://github.com/boostorg/timer/blob/develop/test/Jamfile.v2#L30 One downside of it is that for `inspect` to build, a more complete Boost checkout is required (it needs `filesystem` and `regex` at least). But if that's not a concern, the above can be used by those wishing to add `inspect` to their test suites.
participants (14)
-
Adam Wulkiewicz -
Alexander Grund -
degski -
Gavin Lambert -
Glen Fernandes -
Hans Dembinski -
John Maddock -
Mateusz Loskot -
Mike -
Niall Douglas -
pbristow＠hetp.u-net.com -
Peter Dimov -
Raffi Enficiaud -
Rene Rivera