Boost logo

Boost :

From: Hans Dembinski (hans.dembinski_at_[hidden])
Date: 2019-08-22 09:06:08


> On 22. Aug 2019, at 09:54, Paul A Bristow via Boost <boost_at_[hidden]> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk