does it make sense to incorporate all libraries into my project e.g. in _3rd_party_libs_ folder ?
Do whatever you want, but keep it consistent. I do note that you've listed examples such as boost/sqlite; these should be standard in your dev environments and not included in your project, unless you depend on say some funny version of boost.
how to handle lib include paths in my modules (environmental variable, relative paths, git submodules, etc. ) ?
This is what your build system - CMake - is for. Your source code just has #include <third_party_lib.h> without worrying about where they are located.
should I always build external libs from source or just used their binaries ?
Prefer binaries by default, unless you have a good reason to build from source every time.
TLDR;
Should you add the source? YES
Should X add the source? DEPENDS
Here comes the why...
Back in the day, compilation time was an issue even smaller projects had. Compiling your sources and never worrying about caching compiler results was definitely appealing to some. That's one point for libraries irrelevant to you.
Another important one is versioning. Do you really need to version each library separately? Run tests against each one? Distribute it amongst many team members? Libraries are great if you do, and convenient to move around, but again, seems you don't care about this either.
Final point here is, it's an added overhead, and dropping the source files is easier in your case, which gives a very strong point to dropping in the sources rather than using libraries. As you have noticed, once you make a single compiler setting change, you have to chase all the dependencies otherwise.
I know all this from experience:
For Swift projects, I definitely use frameworks (libraries) and link against them, since it's easy to configure using Xcode. I also really need the versioning, tests, and decoupling there, so that's why.
For Mono (C#) projects, for Unity, I started with the hip approach of breaking down the project into libraries, compiled and tested each one, which was great... but once I dropped the libraries into Unity, all sorts of issues happened, from the hacked version of Mono Unity uses, to simply the sometimes different behavior the code exhibits when changing platforms. Not having a single IDE here to manage all the libraries was a true pain, so putting all source within Unity was a huge win for productivity.
Finally, most relevant to you, a C++ game project I worked on. A game engine, network realtime client, network HTTP client, AI, and a persistence store were written for this game, just on the client side. What did I opt for? CLion + Libraries. Even though I was using libraries, it didn't feel like I was. All the sources were in the CLion IDE project, and by composing CMakeLists, I was able to trigger all builds and link them in a single stroke.
As a conclusion, I would say using libraries is a future-proof solution, but also a premature optimization if not needed. As far as I could ascertain from your situation, switching from MSVC to Xcode will be a pain if you are gonna have multiple build target. So, just drop it in and maintain as much isolation as possible for when the time when you might need to use libraries.
P.S: I am having a similar dilemma these days with docker. Should I compose? Should I just run locally? .. etc. Also Elixir, as it allows you to build Applications within the same application.. Should I do that? Or separate the app into the so-called micro-services? ... etc. There is no silver bullet, always measure yourself, as YMMV.
Best Answer
I would suggest creating a deployment MSBuild file that copies your files to the various destination directories. This will keep all your deployment rules in one place, and allow you to change both source and destination without impacting your other projects.
MSBuild has globbing features that will allow you to group your framework and utility features together and talk about them as a group. Since Visual Studio projects are MSBuild projects, you could probably find a way to include the deployment project in your solution.
Is there a reason you would like to deploy from the IDE? I would suggest you have a stand alone deployment step. Including deployment in the normal compile process can lead to confusion when there are build errors or copy errors. Mismatched versions end up in a library directory and people forget and waste time.