We probably ought to change the layer name from hack to something more descriptive. Maybe source_migration?

Layer name has been changed to source_migration. I believe this is ready to merge if someone approves.

I moved sqlite entirely out of source into source_migration for all platforms. The proposed idea is that we would move every library from source into source_migration as we were able to make them compatible, then eventually replace source with source_migration.

I suppose it might also make sense to remove sqlite from facebook in this PR.

Thanks for looking into this!

I suggest to avoid moving or duplicating files, for a matter of maintenance and git history.
It would be better if the source_migration layer just acts as a proxy toward the source layer of the libraries that are migrated.

In pratice: for each library that also supports macOS and Windows, you mirror its CMake files (Findxxx.cmake and its CMakeLists.txt) in the new source_migration folder, but they actually include() the CMake files of the source layer and nothing else.
This way we don't need any moving or duplication and when we are done we just delete/drop the source_migration layer.
Same thing for the utils.cmake file, just include the source layer one.

Updated as per comment by @Smjert to include the file in the source layer, and make the appropriate changes there.

The changes look good, though it would be better if the silencing of warnings coming from the third party libraries is reproduced also for Windows.

I added the warning suppression for Windows as well. This does introduce a new warning due to /W3 being overridden by /w. I spent hours trying to resolve it by being able to remove /W3 from the third party targets, but ultimately I think it requires a refactor of how the options are set that should be handled separately from this PR.

I think it requires a refactor of how the options are set that should be handled separately from this PR.

What you mean here?
The way things are layed out are quite intentional, especially for third party libraries and submodules, where you want those extra flags to be put as last in the command line and also solve some of the variable/target scopes issues that exists due to the CMakeLists.txt position in the hierarchy.

If your intention is to solve the /W3 issue, why not just replicate what the policy does?
You can simply remove that /W3 by changing the contents of CMAKE_C_FLAGS and CMAKE_CXX_FLAGS in the flags.cmake file, and then re-add it only on the targets you want.
Namely, on the bottom of flags.cmake you have:

Or even better, if this is again your "only" issue, is to update the minimum required CMake version to the latest stable.
We don't find this an issue as it may sound because CMake is pretty easy to obtain already built, and I've successfully used it till now on CentOS 6 or if you really need to build it, again it's as easy as run a single script they provide to build it (or you can use a recent enough CMake you have in the system if you prefer).

Turns out it was all unnecessary anyway... If you just set /W0 (which has the same meaning) instead of /w, you don't get an error about repeated flags. If this passes on CI now, it should be good to merge.