4 ms·

> (...) and the rest of us have to suffer for it every time we experiment with a 1 line of code change to those files. If you feel this is an issue then why do

> (...) and the rest of us have to suffer for it every time we experiment with a 1 line of code change to those files. If you feel this is an issue then why don't you move it to an independent submodule that can be compiled independently? That means you can build it in parallel along with the whole project, and in the end you just link the resulting binaries.

jart 2y ago
I just wrote a new server instead. There's nothing I won't do, no lengths I'm not willing to go, when it comes to cutting back on build latency.
- chipdart 2y ago
  > I just wrote a new server instead. I'm sorry, this makes no sense at all. Why would anyone write a new server just because a small component was taking a minute to build?
  - wiseowise 2y ago
    It makes no sense at all that person concerned with slow build time rewrote slow component to compile faster?
- gary_0 2y ago
  I follow the same philosophy, to the point where at this point I barely use the STL; most of that template-heavy junk has been replaced in most of my projects. For instance, most of what I typically used <iostream> for was replaced with a 150-line .h (plus a 50-line .cpp that uses explicit template insantiation and a <charconv> include). {fmt} was too heavy for me. And I'm locked into C++17 because C++20 seems to double down on the 20k-line header madness. When I was stuck with C++ codebases that forced me to take a mandatory coffee break every time I needed to run a bit of new code, it made me a little bit insane! Never again.
fsloth 2y ago
” If you feel this is an issue then why don't you move it to an independent submodule that can be compiled independently?” If it’s a header, you necessarily can’t. Header gets included every time you want to compile code that depends on a header. Compilers may offer precompilation etc but if the code you want to change has direct dependency to a large header you need to recompile all of the dependencies. This is one of the painpoints C++.
- pjmlp 2y ago
  It is a pain point of build management regardless of the language, even with a language having proper modules one can have a cascade build, if the public interface or module ABI is impacted. C++ modules are here, unfortunely outside VC++ and clang latest, plus MSBuild or CMake/ninja, they are not an option.
  - papichulo2023 2y ago
    Are they? According to some people (github issue to support cpp modules on vscode) the standard is mess and is likely to go away. VSCode doesnt support modules atm.
    - pjmlp 2y ago
      Visual Studio is what matters. VSCode is never going to be as good, you are better of with Clion then.
      - fsloth 2y ago
        This! As win/mac user Visual Studio is my preferred tool, but in MacOS Clion (with vscode for few random workflow things not supported in Clion) is an adequate replacement (but Visual Studio remains king). VSCode can be used as an industrial editor if one likes to, but if it does not feel right, it’s not a skill issue.
    - int_19h 2y ago
      Assuming that you're referring to https://github.com/microsoft/vscode-cpptools/issues/6302 https://github.com/microsoft/vscode-cpptools/issues/6302, I see two comments along these lines, neither of which is from actual implementers. That isn't evidence either that the standard is a mess, nor that it's likely to go away. The reason why this is taking such a long time is because the entire approach is a rather drastic change to how C++ compilers usually work, and C++ compilers (or even frontends, such as the stuff used by IDEs) are complicated things that aren't trivial to make major changes to.

jart 2y ago

I just wrote a new server instead. There's nothing I won't do, no lengths I'm not willing to go, when it comes to cutting back on build latency.

chipdart 2y ago
> I just wrote a new server instead. I'm sorry, this makes no sense at all. Why would anyone write a new server just because a small component was taking a minute to build?
- wiseowise 2y ago
  It makes no sense at all that person concerned with slow build time rewrote slow component to compile faster?
gary_0 2y ago
I follow the same philosophy, to the point where at this point I barely use the STL; most of that template-heavy junk has been replaced in most of my projects. For instance, most of what I typically used <iostream> for was replaced with a 150-line .h (plus a 50-line .cpp that uses explicit template insantiation and a <charconv> include). {fmt} was too heavy for me. And I'm locked into C++17 because C++20 seems to double down on the 20k-line header madness. When I was stuck with C++ codebases that forced me to take a mandatory coffee break every time I needed to run a bit of new code, it made me a little bit insane! Never again.

fsloth 2y ago

” If you feel this is an issue then why don't you move it to an independent submodule that can be compiled independently?” If it’s a header, you necessarily can’t. Header gets included every time you want to compile code that depends on a header. Compilers may offer precompilation etc but if the code you want to change has direct dependency to a large header you need to recompile all of the dependencies. This is one of the painpoints C++.

pjmlp 2y ago
It is a pain point of build management regardless of the language, even with a language having proper modules one can have a cascade build, if the public interface or module ABI is impacted. C++ modules are here, unfortunely outside VC++ and clang latest, plus MSBuild or CMake/ninja, they are not an option.
- papichulo2023 2y ago
  Are they? According to some people (github issue to support cpp modules on vscode) the standard is mess and is likely to go away. VSCode doesnt support modules atm.
  - pjmlp 2y ago
    Visual Studio is what matters. VSCode is never going to be as good, you are better of with Clion then.
    - fsloth 2y ago
      This! As win/mac user Visual Studio is my preferred tool, but in MacOS Clion (with vscode for few random workflow things not supported in Clion) is an adequate replacement (but Visual Studio remains king). VSCode can be used as an industrial editor if one likes to, but if it does not feel right, it’s not a skill issue.
  - int_19h 2y ago
    Assuming that you're referring to https://github.com/microsoft/vscode-cpptools/issues/6302 https://github.com/microsoft/vscode-cpptools/issues/6302, I see two comments along these lines, neither of which is from actual implementers. That isn't evidence either that the standard is a mess, nor that it's likely to go away. The reason why this is taking such a long time is because the entire approach is a rather drastic change to how C++ compilers usually work, and C++ compilers (or even frontends, such as the stuff used by IDEs) are complicated things that aren't trivial to make major changes to.