Use an linter for CMake code in TriBITS?

[bartlettroscoe]

CC: @KyleFromKitware

Description

A good fraction of the comments in recent TriBITS PRs relate to basic CMake language issues. These types of issues can be detected using a static analysis tool (aka, a linter). It is generally agreed that it is better to catch these types of issues using an automated tool an focus human effort of a review on issues automated tools can't easily catch (see 5. Always run automated code checkers).

It looks like there exists such a tool for CMake:

• https://github.com/cmake-lint/cmake-lint

[bartlettroscoe]

Hello @KyleFromKitware, would you consider evaluating the tool:

• https://github.com/cmake-lint/cmake-lint

and try running it one some CMake projects, including TriBITS and see how it works?

Or, is there some other CMake linter you know about that we could try?

[bartlettroscoe]

And we might look into a broader set of tools for CMake:

• https://cmake-format.readthedocs.io/en/latest/

[KyleFromKitware]

https://github.com/cmake-lint/cmake-lint looks like it only catches the most basic of issues (extra spaces, etc.) It doesn't look like it checks quoting and such.

You're not the first customer to express interest in a linter. Perhaps we could either expand cmake-lint or write our own?

[bartlettroscoe]

You're not the first customer to express interest in a linter. Perhaps we could either expand cmake-lint or write our own?

@KyleFromKitware, it seems like the CMake user community should fund an effort to use the CMake parser code that is already in CMake to create a linter. Could we extend cmake-lint to add these checks? That might be easier than starting from scratch.

But given that the current CMake language has such serious fundamental problems and there is a glaring need for a new CMake language (see here), I don't know that we could get a linter for the current CMake language funded. Do we keep investing in the existing CMake language or do we bit the bullet and create a new language?