All of that to compensate for the fact that the C/C++ community never came up with a decent & standardised build system. I never have to deal with issues like these when writing software in Rust & Go.
I agree that there is no easy way when it comes to build systems on C/C++ (other than known environments for specific platforms, like Visual Studio).
Also, following the reasoning line of your comment you can make a parallel conclusion: the C/C++ community and level of adoption are so big that the people of Rust & Go had to put together a "decent & standardised build system" to gain traction and consideration.
So you’ve never had problems with vendoring in Golang? At least this particular strategy makes it trivial to have different versions of different libraries in different projects on the same machine, each project entirely manages its own dependencies without any reliance on language specific tools. That’s why this kind of library format is so extremely popular.
With that being said, having a standardized build system would be nice, but it wouldn't solve the underlying problem here which is that portability is often not regarded as important enough to merit thinking about and designing for at the start of a project.
The consequence of this is that it creates a system in which C programmers have very little trust in one another's code.
I write a lot of C for ARM and I am often hesitant to use libraries that I can't inspect in a reasonable amount of time because I have been burned by e.g. liberal use of type punning which results in bus conflicts as it's idiomatic and works just fine on x86, but is ultimately undefined behavior in most circumstances. (Rant: Just use memcpy, please! Argh!)
