Conversation
.clang-format
Outdated
| @@ -1,5 +1,11 @@ | |||
| --- | |||
| # /.clang-format -*-config-*- | |||
There was a problem hiding this comment.
This will make it slightly harder to keep the .clang-format up to date because clang-format will want to rewrite it when you dump the config.
I believe it's right now at clang-format-17.
clang-format-19 --style=file:.clang-format --dump-configwill produce the file that clang-format believes it read, adding the options that were defaulted.
There was a problem hiding this comment.
This will make it slightly harder to keep the .clang-format up to date because clang-format will want to rewrite it when you dump the config.
I'm OK to remove this file, but wouldn't be consistent for other linters? I think I would like to change it manually (using --dump-config into a temporary file). What do you think?
btw, I tried with clang 17/18/19, and I cannot get the current config. Would you like to update it with clang-format-19 in this PR? (The required changes will be applied in later commits or in a new PR).
There was a problem hiding this comment.
It's the comment itself that gets lost. clang-format configs are generally one way upgradable but otherwise stable. That is, clang-format-N+1 will read an N file and default the elements that are added, so that when you run dump-config you get a file that only cf-N+1 understands but that produces the same output as the old config.
Caveats around syntax that clang-format didn't used to understand, of course.
We don't need to be eager about upgrading unless we decide we need the new knobs.
I've left myself a TODO to see if clang-format changes matter for the few files we have, and if so, we probably don't need to upgrade.
It's just that the comments are easy to get lost, and I wouldn't want anyone to read too much into that.
neatudarius
force-pushed
the
improve-flows
branch
from
1287f52 to
d12cd07
Compare
neatudarius
force-pushed
the
improve-flows
branch
from
7c6b652 to
2cffd23
Compare
|
I'll take a look at what the lint fixes would do before approving this, but I'm in principle in favor of all it. I have no strong feelings about markdown, shell, yaml, and json formatting -- all of them are terrible and I don't particularly care. Slight preferences about C++ formatting, although as long as clang-format can put things back in canonical form it's only a slight preference. And with |
| # Expected tools to be installed on the system. A pre-check is done to ensure all tools are installed. | ||
|
|
||
| set -e | ||
| set -x |
There was a problem hiding this comment.
Remove the execution trace option?
It's very noisy to use the script with this set.
|
Related PR - #52 . Will discuss with @steve-downey the approach. |
|
Put this PR on hold until we solve similar issue/discussion for beman.exampler. |
I think a good way to do that would be to mark it as a draft PR. |
It seems it cannot be put back to draft. I will temporary close it. |
3 participants
TLDR: scripts for local and CI flows. #1 #2 #11 #16
The codebase (e.g. C++ files) are not updated in this PR. I will make a new PR an update
mainand rebase this branch until this PR becomes green!===========================================================================
Updates already applied:
Update toolchain files (
etc/tree)etc/. Add license. Run linters.CMAKE_CXX_STANDARD(tested with C++20, C++23 and C++26)Configure linters:
clang-format19, tested on Ubuntu 24.04.clang-formatshell-check.shellcheckrcmarkdownlintnpmon Ubuntu 24.04.markdownlint.jsonyamllintyamllintcmake-format.cmake-formatScripts: Uniform testing and linting local and CI environments! Full usage in scripts/README.md.
scripts/lint.sh: Script used to lint some or all files in the project.--fix).scripts/run-tests.sh: Script used to run tests on local and CI environments!--preset). Can set a C++ standard (--std).New CI flows:
github/workflows/ci_tests.yml: usescripts/run-test.shand a matrix config to run all tests.{gcc-13, gcc-14, clang-17, clang-18, clang-19}. Note: Expected gcc-13 to fail with C++26.{20, 23, 26}github/workflows/ci_lint.yml: usescripts/lint.shto make a PR have failed jobs if linting fails.{--cpp, --shell, --markdown, --yaml, --cmake}===========================================================================
Next steps:
ci_tests.ymlare green and can be deployed inmain.ci_lint.ymlare red. I will push start making commits to fix linter errors, after we agree a direciton.