Re: OpenMAMA static analysis
|
Duane Pauls
For Visual Studio, it appears as though the support lifecycle model changed after VS 2010. While VS2012 and VS2013 are already EOL, VS2008 and VS2010 are still on extended support. If the intent is to be cautious, it probably makes sense to wait until MS ends extended support before dropping support from OpenMAMA.
The end of extended support dates are: VS2008: 2018-04-10 VS2010: 2020-07-14
Cheers, Duane
From: openmama-dev-bounces@... [mailto:openmama-dev-bounces@...]
On Behalf Of Frank Quinn
Sent: Tuesday, September 19, 2017 11:17 AM To: Bill Torpey Cc: openmama-dev Subject: Re: [Openmama-dev] OpenMAMA static analysis
The question of support for visual studio is one for the community which I'll actually pose on a separate thread with its own subject so that people might read it, but since VS2013 only went EOL from microsoft a year ago, I expect there are a few out there still using it.
Last time we asked, there were still some 2008 users out there too. As you can see, we actually only got rid of 2005 support as recently as 2 years ago (I was keen to do it as 2008 introduced proper msbuild support so we could finally upgrade to newer visual studio project formats). I'm keen to move forward too, but I don't want to alienate our client base either, so any movement forward would need to have 100% community support.
Generally for static code analysis, I'm all for it - it tends to prevent issues that weren't even considered. However it would be a lower priority for me behind a few other outstanding CI tasks related to making us more comfortable in merging changes, namely:
It does continue the gradual increase in sophistication for CI we have had in the last couple of years though... first of all we got unit tests working, then we got warnings removed on linux, now they're gone on windows, but yes I definitely want to always be moving towards a better CI environment which includes static analysis... but they tend to be slow burning tasks so it might take a while to be part of our day-to-day maintenance, but I'd happily accept any static code analysis related changes in the interim.
Cheers, Frank
On Tue, Sep 19, 2017 at 2:08 PM, Bill Torpey <wallstprog@...> wrote: Hi Damian:
Thanks for the feedback. I’ve made some comments below.
Regards,
Bill
Right now, getting static analysis working with other tools is somewhat dependent on the build tooling. I use a custom build script that runs scons under bear to create the compilation database required by my scripts. The build script is somewhat specific to my environment, so I don’t know how useful it would be to others. but I’ve attached it just in case.
However, once you’ve got a compilation database built (and cppcheck installed), you can use the scripts at https://github.com/btorpey/static to run analysis using both clang and cppcheck, e.g.:
cc_cppcheck.sh -i common/c_cpp/src/c/ -i mama/c_cpp/src/c/ -c 2>&1 | tee cppcheck.csv
Similar scripts exist for clang-check and clang-tidy (although afaict clang-tidy does everything that clang-check does and more).
I guess I’m curious about what others think about relative priorities, and/or whether there is are natural “owners” for different parts of the code-base that might want to have input.
The only thing I would add, and related to your comment about the scope problems, is any changes will need to take into account the breadth of compilers OpenMAMA has to support and that unfortunately means continuing with the C89/C99 cross breed that older versions of Visual Studio rely on. This isn't so much an OpenMAMA stylistic choice as one that's been forced on us by compiler support, but the wider user community relies on us continuing to adhere to this as a standard (for now ;-)).
Curious if there’s a timetable for requiring VS2013 (the first MS compiler that doesn’t have this problem). As you’re probably aware, the K&R style is “officially” frowned on, at least in the C++ Core Guidelines (https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#es21-dont-introduce-a-variable-or-constant-before-you-need-to-use-it). I notice that even some of Frank’s side projects (zmq, omnm) deviate from K&R style, which is understandable given how archaic it is.
In the meantime, it’s easy enough to filter out those warnings.
Thanks. I’ll send out a link when the article is complete — certainly interested in any feedback. In the meantime, you may want to check out the other articles in the series: http://btorpey.github.io/blog/categories/static-analysis/
You’ve already seen some, just under another moniker: https://github.com/pulls?utf8=%E2%9C%93&q=author%3Abill-torpey-ullink+
|
|
|