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_at_[hidden]> 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