4 ms·

Really cool read. One thing which I was curious about, but is not completely related to the article, is how the workflow of making changes to a big project like

by pythux 7y ago

Really cool read. One thing which I was curious about, but is not completely related to the article, is how the workflow of making changes to a big project like Clang looks like. Is there some « watch » mode to iterate faster without needing to rebuild? What kind of tooling/editor is recommended, is there some linting support? Is it possible to quickly identify a subset of tests to run for the changes made? (In this case I assume there are tests for lambda parsing?).

erichocean 7y ago
> Is it possible to quickly identify a subset of tests to run for the changes made? Bazel makes that simple for C++ projects.
muricula 7y ago
The llvm hacking guide has answers to some of these questions: https://clang.llvm.org/hacking.html https://clang.llvm.org/hacking.html There is more information in the llvm docs as well. I don't know about a watch mode, but I'm not sure how much that would save you as you'd constantly be relinking a very large project. It might even be counter productive. As for tooling and editors, the build system is well integrated with visual studio on Windows, and I think xcode on mac os. For linting the llvm project has clang-format and clang-tidy which are excellent tools for any C++ project. I believe there is an extensive system test suite written in Python described in the hacking docs.
mort96 7y ago
My workflow was extremely simple; a terminal window, with cutting-edge tools like ripgrep to search for patterns and neovim to edit. When I had made a change, I ran make. When I wanted to test out a change, I had print statements in the clang source code and wrote a small test file which I could use to decide whether the prints I saw matched the prints I expected to see. Revolutionary stuff, I know. One trick I like when working with huge projects is to do my printf debugging with `fprintf(stderr, ...)` instead of the project's standard logging, just to avoid having to fight with log levels and such. (These print statements should obviously be removed once they're no longer necessary; here again, using fprintf helps, because they stand out.) I didn't even think about tests, but I'm happy to report now that the entire test suite still works after my change. I don't think any kind of test-driven debugging would have worked here; almost none of the challenge was in the actual code behind the feature, it was all mostly just work to try to understand the code base. For example, "Oh, this looks like it's where lambdas are parsed. Let me add a print here and try to compile a file with a lambda to see if I'm right", or "Ok, I think I should end up in this branch if I have a fat arrow token in a lambda expression, let's add a print statement and modify the test file to check if that's true".

by pythux 7y ago

erichocean 7y ago

> Is it possible to quickly identify a subset of tests to run for the changes made? Bazel makes that simple for C++ projects.

muricula 7y ago

The llvm hacking guide has answers to some of these questions: https://clang.llvm.org/hacking.html https://clang.llvm.org/hacking.html There is more information in the llvm docs as well. I don't know about a watch mode, but I'm not sure how much that would save you as you'd constantly be relinking a very large project. It might even be counter productive. As for tooling and editors, the build system is well integrated with visual studio on Windows, and I think xcode on mac os. For linting the llvm project has clang-format and clang-tidy which are excellent tools for any C++ project. I believe there is an extensive system test suite written in Python described in the hacking docs.

mort96 7y ago

My workflow was extremely simple; a terminal window, with cutting-edge tools like ripgrep to search for patterns and neovim to edit. When I had made a change, I ran make. When I wanted to test out a change, I had print statements in the clang source code and wrote a small test file which I could use to decide whether the prints I saw matched the prints I expected to see. Revolutionary stuff, I know. One trick I like when working with huge projects is to do my printf debugging with `fprintf(stderr, ...)` instead of the project's standard logging, just to avoid having to fight with log levels and such. (These print statements should obviously be removed once they're no longer necessary; here again, using fprintf helps, because they stand out.) I didn't even think about tests, but I'm happy to report now that the entire test suite still works after my change. I don't think any kind of test-driven debugging would have worked here; almost none of the challenge was in the actual code behind the feature, it was all mostly just work to try to understand the code base. For example, "Oh, this looks like it's where lambdas are parsed. Let me add a print here and try to compile a file with a lambda to see if I'm right", or "Ok, I think I should end up in this branch if I have a fat arrow token in a lambda expression, let's add a print statement and modify the test file to check if that's true".