[fmt] Update to 12.2.0 [many ports] Fix compatibility with fmt 12.2.0

[xiaozhuai]

• Changes comply with the maintainer guide.
• SHA512s are updated for each updated download.
• The "supports" clause reflects platforms that may be fixed by this new version, or no changes were necessary.
• Any fixed CI baseline and CI feature baseline entries are removed from that file, or no entries needed to be changed.
• All patch files in the port are applied and succeed.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Exactly one version is added in each modified versions file.

Update to 12.2.0

---

fmt 12.2.0 introdue a change that break some downstream ports.
fmtlib/fmt@0007426

https://dev.azure.com/vcpkg/public/_build/results?buildId=133287

---

Related PR:

• libenvpp Fix compatibility with fmt 12.2.0 ph3at/libenvpp#17
• hareflow Fix compatibility with fmt 12.2.0 coveooss/hareflow#20 [hareflow] update to 0.3.0 #52465
• cadons-ctus Fix compatibility with fmt 12.2.0 Cadons/ctus#62 #463ef37c108ec6b87a1ead4a5f0f7808b7fa5e91
• vowpal-wabbit fix: compatibility with fmt 12.2.0 VowpalWabbit/vowpal_wabbit#4922
• ctbench Fix compatibility with fmt 12.2.0 JPenuchot/ctbench#42
• folly Fix compatibility with fmt 12.2.0 facebook/folly#2661
• vtk (On a self-hosted GitLab instance, no PR at this time)
• irsdk-cpp Fix compatibility with fmt 12.2.0 vrkit-platform/irsdk-cpp#1
• saucer (The latest version seems not using fmt anymore)
• openal-soft Fix compatibility with fmt 12.2.0 kcat/openal-soft#1297
• sdflib (It indirectly depends on fmt, and this update has exposed an issue with its implicit header file passing.)
• vanillapdf (It indirectly depends on fmt, and this update has exposed an issue with its implicit header file passing.)
• paraview (On a self-hosted GitLab instance, no PR at this time)
• fbthrift Fix compatibility with fmt 12.2.0 facebook/fbthrift#702

[Thomas1664]

Rather than all these patches, would it be easier to just create the fmt/core.h file in the fmt port which then includes fmt/format.h?

[xiaozhuai]

Rather than all these patches, would it be easier to just create the fmt/core.h file in the fmt port which then includes fmt/format.h?

NO, I don't think patching the fmt port to make fmt/core.h include fmt/format.h again is the right direction.

fmt/core.h still exists. The issue is that upstream intentionally changed its behavior: it now includes fmt/base.h, and fmt/format.h is only included when FMT_DEPRECATED_HEAVY_CORE is explicitly defined. Upstream also documents in the header that using fmt::format through fmt/core.h has been deprecated since fmt 11 and now requires an explicit opt-in.

If vcpkg changes fmt/core.h to always include fmt/format.h, vcpkg's fmt package would behave differently from upstream. That would hide real missing-include issues in downstream ports. The better long-term fix is to update the affected ports to include the headers they actually need, which is what these patches do.

At the same time, I also submitted a PR to the affected upstream repo—not to intentionally complicate matters, but because we really should do this.

[Thomas1664]

fmt/core.h still exists.

Sorry, my suggestion was based on the assumption that fmt/core.h was removed.

At the same time, I also submitted a PR to the affected upstream repo—not to intentionally complicate matters, but because we really should do this.

Yes, thanks for doing this.

[blavallee]

FYI, we just pushed a new release (v0.3.0) of hareflow containing the fixes. ref

[xiaozhuai]

@blavallee Thank you, I will update this pr as soon as the ci finish.

[xiaozhuai]

The following error occured

FINAL LINK: command "C:\PROGRA~2\MICROS~2\18\BUILDT~1\VC\Tools\MSVC\1451~1.362\bin\Hostx64\x64\link.exe @CMakeFiles\vtkpython.rsp /out:bin\vtkpython.exe /implib:lib\vtkpython.lib /pdb:bin\vtkpython.pdb /version:0.0 /machine:x64 /nologo /debug /INCREMENTAL /subsystem:console /MANIFEST /MANIFESTFILE:Wrapping\Python\CMakeFiles\vtkpython.dir/intermediate.manifest Wrapping\Python\CMakeFiles\vtkpython.dir/manifest.res" failed (exit code 1140) with the following output:
LINK : fatal error LNK1140: limit exceeded for program database; link with /PDB:NONE

LINK : fatal error LNK1201: error writing to program database 'D:\b\vtk\x64-windows-static-md-dbg\tools\python3\Lib\site-packages\_vtkmodules_static.cp312-win_amd64.pdb'; check for insufficient disk space, invalid path, or insufficient privilege

I just baseline it.

vtk[all]:x64-windows-static-md=feature-fails
vtk[core,atlmfc,cgns,cuda,debugleaks,fontconfig,gdal,geojson,libharu,libtheora,mpi,netcdf,opengl,openmp,openvr,paraview,proj,python,qt,seacas,sql,tbb,utf8,vtkm]:x64-windows-static-md=combination-fails

[xiaozhuai]

This pr is stable now, and ready for review.

[BillyONeal]

This resulted in a bit of a SNAFU with the reviewing tools resulting in #52485

Several of the patches have incorrect CRLF line endings rather than LF line endings. We can't ban all CRLFs in patches because patched sources that themselves contain CRLFs will have CRLFs.

However, this is a green build and a huge update to an important library and I don't want to reset build over what is morally a style change. I'll just say in future to try to double check that produced patch files are LF. git diff --output blah will do the right thing, git diff > blah on PowerShell will not.

[xiaozhuai]

All these works are done on a mac, if a patch file contains CRLF, then the source file itself must have CRLF, how should we deal with this situation?

[BillyONeal]

All these works are done on a mac, if a patch file contains CRLF, then the source file itself must have CRLF, how should we deal with this situation?

I just try to make sure all patches are made by git diff --output. In particular the AI tools love to do this wrong. It works in vcpkg's install because we pass a pile of flags that tell git to ignore line endings in vcpkg_apply_patches; it just makes subsequent editing of the same ports in the future somewhat more annoying when manually reconstructing the commit history.

(As for making the review tool no longer angry, that's why I did #52485 )