This and RapidJSON as well are header only and so it should be very simple to use the system provided version by commenting out the O3DE package for them. The problem is that the O3DE build system will try and fail to search for a CMake find module and return an error when doing this. Ideally this is solvable through using the strategy demonstrated here https://github.com/o3de/3p-package-source/pull/205 where the find module itself is modified. This is difficult to produce patches for, however, and even more difficult to do so in a way that is synced with a fork of O3DE, since each package this is done for needs to be rebuilt and rehosted manually with the find module changes. The best solution would be to have engagement from upstream to help get the PR above and equivalent PRs for other dependencies merged.
This and RapidJSON as well are header only and so it should be very simple to use the system provided version by commenting out the O3DE package for them. The problem is that the O3DE build system will try and fail to search for a CMake find module and return an error when doing this. Ideally this is solvable through using the strategy demonstrated here https://github.com/o3de/3p-package-source/pull/205 where the find module itself is modified. This is difficult to produce patches for, however, and even more difficult to do so in a way that is synced with a fork of O3DE, since each package this is done for needs to be rebuilt and rehosted manually with the find module changes. The best solution would be to have engagement from upstream to help get the PR above and equivalent PRs for other dependencies merged.