<story><title>Hacking on Clang is surprisingly easy</title><url>https://mort.coffee/home/clang-compiler-hacking/</url></story><parent_chain></parent_chain><comment><author>atq2119</author><text>The article mentions debug build time as a legitimate pain point about the LLVM project. General good advice, which unfortunately isn&amp;#x27;t enabled by default: use dynamic linking, make sure you&amp;#x27;re using lld, enable split dwarfs (and -Wl,--gdb-index for faster gdb load times!), enable optimized tablegen[0]. ccache doesn&amp;#x27;t hurt but isn&amp;#x27;t actually such a big benefit unless you switch between branches a lot.&lt;p&gt;Oh, and buy a Threadripper. Seriously, you won&amp;#x27;t regret it.&lt;p&gt;[0] TableGen is LLVM&amp;#x27;s internal DSL swiss army knife. You can separately enable optimizations for TableGen independently of optimizations in the resulting LLVM builds, which you should basically always do unless you&amp;#x27;re working on TableGen itself.</text></comment>
<story><title>Hacking on Clang is surprisingly easy</title><url>https://mort.coffee/home/clang-compiler-hacking/</url></story><parent_chain></parent_chain><comment><author>pythux</author><text>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&amp;#x2F;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?).</text></comment>