Hi,

What I'll write below might be a bit out of context, but it's something that troubled me a lot and I always wanted to say while watching this group. I have a big issue with the statement below. The TL;DR is that the build system should not encode what's already in the source code, because that's extra-effort and there's always a chance of messing things up.

On Thu, Jan 31, 2019 at 9:28 PM Titus Winters <titus@google.com> wrote:
If my build system has already encoded all of my dependencies in a secondary layer (my build files), do I care about any of these concerns? 

If there is something that I always complained about was this. Why do we always have to encode the dependencies twice? My main concern regarding CMake is the fact that it's just another macro language that tries to specify what we already state in the source code when we currently do #include. In my opinion a proper build tool should specify only things that are not explicitly stated in the source code, like build flags, installation paths (libraries/header collections).

I used for a while Vlad Petric's akro: https://github.com/vladpetric/akro to build my sources. What that does is you basically specify an „entry point”, and then assumes that if you #include "utils/string_utils.h" you might have a "utils/string_utils.cpp" to contain the code described in the "utils/string_utils.h". This is what usually happens in normal projects, so this assumption is quite safe. The build system uses `gcc -M` to determine where the dependecies might lie with the flags that the build system specifies, and then tries to find the source files based on the path of the include files. If akro finds such source files, it will add them to the list to be compiled and afterwards linked together to form the executable.

Akro is by no means perfect, but definitely makes things a lot simpler. The point that I'm trying to make is that one of the most painful things about C++ right now is CMake - it feels like a weight tied to one's neck - not only writing C++ is hard, but whenever you create a new file you have to be sure that the magic CMake statements also catch that file properly. And one newbie might exclaim that they already said they wanted utils/string_utils in when they wrote #include.

I am biased; I dislike CMake a lot, and I think that in the end it's just another piece that has to go away in the search for a truly „modern C++”. My point is that if you're trying to design the future of C++ tooling with CMake in mind, you should think again; the lack of consistency in that tool is outrageous, and the only way to truly fix it is to replace it completely. And, of course, the fact that the build system should be used to specify things that one doesn't specify in the source code; and then we should ask ourselves why we don't specify those things in the source code. Current build systems become too complicated because they do too much when they should do a lot less.

Sorry for my huge rant, and I hope I didn't take too much of your time.
  Dorin Lazăr