<div dir="ltr">Thanks for your replies.<br>I wasn&#39;t subscribed to the mailing list properly, so my reply may mess up the reply chain a bit, sorry about that.<br><br>A few replies<br><br>&gt;  Is standardizing cmake as part of C++, at least within the mandate of tools, something we can all agree on?<br>Definitively not. I think that cmake is terrible and that better options exist. Of course people will disagree and a war will rage on. But, do we actually need a standard build system ? I&#39;m not convinced. We do, however, need a standard package manager.<br><br>Maybe build systems can manage to talk to each others. CMake already has a &quot;server mode&quot; mode to talk to IDEs. If that communication protocol could be extended so that one can, for example, include a cmake project in a build2 or meson project, or the other way around, we wouldn&#39;t need to force a build system on people.<br><br>I do think that&#39;s doable. After all, all build systems do the same thing, they all have the same input and outputs.<br>The same protocol could be used for the IDE/build system integration as well as hopefully build system/clangd integration ( or something similar if other vendors wish to offer a tooling/indexing server)<br><br>&gt; Well, taming the preprocessor is one reason why the Modules TS doesn&#39;t support exporting macros.<div><br></div><div>And it&#39;s a great start ! I don&#39;t think however it is sufficient. Notably, I&#39;d like a way for a declaration ( or even definition ) to be part of the AST even if that symbol is not included in the compiled TU in the current system/configuration.</div><div><br></div><div>I did some thinking on that particular issue and I&#39;m interested in gathering feedbacks <a href="https://hackernoon.com/undefining-the-c-pre-processor-c4eeb3d06e1f">https://hackernoon.com/undefining-the-c-pre-processor-c4eeb3d06e1f</a> </div><div><br></div><div>&gt; <font color="#000000">If you are interested in C++ refactoring get in touch with me. we are working for more than a decade on practical refactoring and for your example of renaming the preprocessor is just one hurdle.</font><br><span style="color:rgb(0,0,0)">The others are intrinsic in the language and won&#39;t go away.</span></div><div><span style="color:rgb(0,0,0)"><br></span></div><div><font color="#000000">Do you have some concrete examples ? Clang tools are pretty reliable if parts of your code are not #ifdef-ed away (even if writing them takes a bit of care).</font></div><div><span style="color:rgb(0,0,0)">I&#39;m hopping the performances issues, notably in regards to indexing and IDEs integration, are solved by modules. I guess it will still be a few years before we get significant data about that.</span><br></div><div><span style="color:rgb(0,0,0)"><br></span></div><div><font color="#000000">I do agree that even the simplest tool needs to be a full fledged compiler front end, that&#39;s why clang is the best thing since sliced bread.</font></div></div>