Chris Thrasher

> FetchContent is nice, but probably we should use it manually once and then check in the sources (that's what you suggest, if I understood correctly). I was referring to...

> The first case made every single dependent code break, the second still broke everything with "use latest version" policy. I'm not proposing we use FetchContent to track the latest...

I'm going to close this issue for now because I need to figure out more about a viable implementation. I don't want this issue cluttering up the issue tracker if...

Okay then I'll reopen this so we can keep this as our designated spot to discuss dependency management. I won't personally have much to share about this in the short...

That's a totally reasonable solution. I don't think anyone on the team or other frequent contributors have much experience with it but I'm sure we'd all love to see what...

I support a solution where the CMake code exclusively uses `find_package` which has a number of benefits while we maintain a vcpkg manifest for users to optionally use if they...

> You can use target_precompile_headers for CMake 3.16 and above. Is there a reason why the 3.0 branch only requires CMake 3.8? I feel like it ought to require at...

Why do you want to include OpenAL from two locations? If SFML already depends on it, why express that dependency again in your own build? Does this problem persist when...

My biggest issue with this PR is that it's solving two somewhat unrelated problems. The first is the problem that all tests are getting symbols from potentially unrelatedly libraries and...

`target_precompile_headers` requires CMake 3.16. I see this PR doesn't change the minimum CMake version requirement. Is it possible that some jobs are failing due to old CMake versions?