This week I've been implementing some formatting and linting tools for my SSG via clang-format and clang-tidy. It took some doing to get them set up, at first I was very confused about what exactly clang was vs LLVM, what power tools was vs the command line version, and how to use all of the above.
First off, it was a breeze to get clang power tools set up as an extension for Visual Studio. It makes the process of setting up a .clang-config file by comparing different formatting styles side by side on your code.
This part was super easy, figuring out what to do with the config file I just made was a bit harder. All the guides I found referred to using something called LLVM, which I remembered being mentioned in power tools so I referred back to that where I was able to install it directly from Visual Studio.
Unfortunately something went wrong insofar as I wasn't able to use LLVM outside of Visual Studio to call clang-format anywhere. Maybe it just didn't set the PATH right, regardless I eventually uninstalled it from there, installed it on its own and set the PATH this time, and was able to start using it to format my SSG files from cmd.
This seemed got tricky as well, as I realized I'd have to write a script with all the relevant arguments to find any cpp files in the directory and format them appropriately. After some investigation I found this process much more painless than expected, and though I haven't written much in the way of scripts I was able to get it figured out through some research and trial and error.
clang-format -i *.hpp *.cpp -style=file --verbose
PAUSE
I wrote a .bat which calls clang-format with the -i argument to edit the files, *.hpp and *.cpp to format files with those extensions, -style=file which searches for a .clang-format file to specify formatting style, --verbose to print the names of files being processed, and PAUSE to let the user see what's happening before closing the cmd. I committed this part and moved to linting.
Next I had to do the same for linting, which I did with clang-tidy. After setting up formatting, the process was much the same with some notable differences. The clang-tidy command was already available due to LLVM being installed, so I got straight to generating a .clang-tidy file with clang power tools and writing another script:
clang-tidy --config="" *.hpp *.cpp --extra-arg=-std=c++17 --
PAUSE
For this script I called the clang-tidy command, set the --config argument to an empty string which makes the command look for a .clang-tidy file, specify the file extensions to look for, set the c++ standard to 17 to prevent errors from the inclusion of std::filesystem, and PAUSE again to let the user see what's going on before proceeding.
This part was a bit tricky as clang kept printing error: invalid argument '-std=c++17' not allowed with 'C'
. I found out from a classmate that this was because .h files are recognized as C headers by clang, so I changed my header files to use .hpp to avoid this. There are other ways to deal with this if you're using clang as a compiler, but for my purposes I just want its linting functionality so this was the best way I could find to do so and still have it lint my header. I then committed this part and moved to the next.
Finally, I exported my settings from Clang Power Tools for contributors to have the option of in-IDE linting and formatting. This was very straightforward, the documentation for Clang Power Tools seems to be a bit outdated and the page describing this process lead to a 404, but it's hard to ignore the big "export settings" button under the Team tab. I fixed an error where I forgot to change the header inclusion to .hpp in the main and committed both files.
Finally I squashed all my commits, made a few more fixes and updated my contributing.md and readme.md.
This was a pretty straightforward lab all things considered, most of the trouble came from settings up clang for use in cmd and figuring out how to write scripts to do what I needed. Increasingly I feel like I'm at a disadvantage using Windows/Visual Studio/C++ as a lot of these processes would be streamlined on other platforms, but hopefully learning how to do things in the convoluted ways Windows supports means that if and when I make the switch it'll be easier. I guess I just wish more developers provided instructions for different platforms and didn't treat one like the default as well. This is something I've run into in my 0.2 assignment a lot as well, for someone just encountering a lot of these tools it can be pretty daunting to decipher how to use them while also reading between the lines to determine which instructions are platform specific - and to what platform.
Top comments (0)