[fmt] update to v11.2.0

[yurybura]

• [x] Changes comply with the maintainer guide.
• [x] SHA512s are updated for each updated download.
• [x] The "supports" clause reflects platforms that may be fixed by this new version.
• [x] Any fixed CI baseline entries are removed from that file.
• [x] Any patches that are no longer applied are deleted from the port's directory.
• [x] The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• [x] Only one version is added to each modified port's versions file.

Fixes #42927 Fixes #43548 Fixes #44042 Fixes #45357 Fixes #39856

[dg0yt]

There is overlap with #44927 wrt wpilib/eigen.

[yurybura]

There is overlap with #44927 wrt wpilib/eigen.

Yes, that's true. But I've already finished with eigen3 and wpilib. Only dependent libraries remain.

[IRainman]

Please update version to 11.2.0

[OhmV-IR]

Alright I've closed my add-latest-wpilib in favor of this pr, made a pr to your fork with the fix for the ompl package that applies to your pr as well

[alxvth]

I don't think updating Eigen to an unreleased version/commit from the master branch is a very good idea. It would come with a bunch of not yet well documented breaking changes compared to the previous 3.4.0 version as listed in this Eigen 3.5 changelog proposal, discussed in this upstream issue.

[yurybura]

I don't think updating Eigen to an unreleased version/commit from the master branch is a very good idea. It would come with a bunch of not yet well documented breaking changes compared to the previous 3.4.0 version as listed in this Eigen 3.5 changelog proposal, discussed in this upstream issue.

Some libraries are already using an unreleased version of Eigen. Having dozens of patches for a library that hasn't had a release in three years is even worse.

[dg0yt]

Would it make sense to cherry-pick some port modifications into indidual PRs?

[yurybura]

Would it make sense to cherry-pick some port modifications into indidual PRs?

For now, it’s more convenient for me to make changes in the current one, since it’s not yet clear how many more changes will be required.

[OhmV-IR]

Would it make sense to cherry-pick some port modifications into indidual PRs?

feel free to take some of my commits off here: https://github.com/yurybura/vcpkg/pull/2, I have fixes for rtabmap and vowpal-wabbit which aren't in here yet

[dg0yt]

For now, it’s more convenient for me to make changes in the current one, since it’s not yet clear how many more changes will be required.

In my experience, offloading some changes for quick separate merges really helps to limit complexity, to avoid merge conflicts and to facilitate focused review.

[BillyONeal]

I cancelled the run to do maintenance on the x64-osx host machine but there were plenty of failures for other triplets to look at.

[nic11]

Hey all

Looks like this PR is now needed to fix spdlog in vcpkg on Arch Linux and Clang 20: https://github.com/gabime/spdlog/issues/3417

As another suggestion, do you think it could be a good idea to switch to spdlog's bundled fmt instead?

[yurybura]

Looks like this PR is now needed to fix spdlog in vcpkg on Arch Linux and Clang 20:

Updating fmt is a big pain because of the large number of dependencies. Cyclic fixing of dependencies takes time.

As another suggestion, do you think it could be a good idea to switch to spdlog's bundled fmt instead?

You can use overlay port in your project and not wait for this PR to complete.

[andre-nguyen]

Updating fmt is a big pain because of the large number of dependencies. Cyclic fixing of dependencies takes time.

Thank you for your service 🫡

[nic11]

Yes @yurybura sorry if that sounded unappreciative, by that message I just wanted to let you know that clang 20 has reached a little bit more rollout. Thank you for reminding about overlay ports, I've applied the update as an overlay port, and it worked without any issue

[dg0yt]

I still think it might be beneficial to cherry-pick some updates into individual PRs.

I have some comments but I'm hesitating to throw them in.

[IRainman]

I still think it might be beneficial to cherry-pick some updates into individual PRs.

We have been waiting for FMT updates since September 2024 and one major version with big improvements has been added to the library. If this PR resolves other long problems, it's much better, actually.

VCPKG is a dependency manger, and all of this is fixes the configs of the packages. Why not? Why reason for more burdensome processes?

P. S. currently I use FMT and fast_float directly because of bureaucracy. And it's make me sad.

[petersteneteg]

Eigens last release is from 2021. Vcpkgs model where all packages have to be compatible with each other is great. But we can't have a package like fmt been held up from updating forever because some other packages have not been updated for years. Either we remove Eigen, or we update/patch it to work with fmt as best we can. Having it delay updating something like fmt is not an option in my opinion. Huge thanks to @yurybura for your work here!

[dg0yt]

I still think it might be beneficial to cherry-pick some updates into individual PRs.

Why reason for more burdensome processes?

I did't ask to delay the PR. I ask to wisely use the time from 'upstream needs at least 30 days notice to do something'. Avoids merge conflicts. Faciltates acceptance of this PR.

[BurningEnlightenment]

btw. it seems like eigen will finally cut a new release soonish:

• https://gitlab.com/libeigen/eigen/-/merge_requests/1897
• https://gitlab.com/libeigen/eigen/-/issues/2907

[BillyONeal]

@IRainman

We have been waiting for FMT updates since September 2024 and one major version with big improvements has been added to the library. If this PR resolves other long problems, it's much better, actually.

Resolving problems doesn't make putting words in other maintainers' mouths OK.

VCPKG is a dependency manger, and all of this is fixes the configs of the packages. Why not? Why reason for more burdensome processes?

The comments asking to involve upstream aren't about config fixes, they are about product code changes. Build systems are kind of our thing and we are much happier to take config changes, but if you look at the comments I made here, they are about changes to the C++ code for which I can't prove correctness.

Please see https://learn.microsoft.com/vcpkg/contributing/maintainer-guide#patching for more rationale.

@petersteneteg

Eigens last release is from 2021. Vcpkgs model where all packages have to be compatible with each other is great. But we can't have a package like fmt been held up from updating forever because some other packages have not been updated for years.

I agree; it isn't clear to me what updating fmt has to do with the eigen changes though. From my perspective it looks like there was an otherwise unrelated PR that got stapled onto this. That's not a problem, but it does mean I'm being careful to not let something we really want (fmt update) blind us into merging a bunch of unrelated stuff we would refuse to merge under normal circumstances.

If there's a statement anywhere from eigen's maintainers suggesting that they don't consider individual numbered releases that meaningful that would also work. I am just nervous about going to another maintainer, picking a random commit which might be full of things that they know are broken and would never release, and recording that in our registry as if they (eigen's maintainers) gave that their seal of approval.

Either we remove Eigen, or we update/patch it to work with fmt as best we can. Having it delay updating something like fmt is not an option in my opinion. Huge thanks to @yurybura for your work here!

Yes, thank you @yurybura and please don't take my questions as 'no'.

[BillyONeal]

btw. it seems like eigen will finally cut a new release soonish:

• https://gitlab.com/libeigen/eigen/-/merge_requests/1897
• https://gitlab.com/libeigen/eigen/-/issues/2907

Awesome, thanks for the pointers! I also asked the maintainers how they feel about just using a release date / SHA in that issue.

[ankurvdev]

If we're a little concerned about picking up an untested unreleased eigen commit then maybe we can try to use the commit

https://gitlab.com/libeigen/eigen/-/tree/1d8b82b0740839c0de7f1242a3585e3390ff5f33

Its from Feb-15 2025 and its the one that onnxruntime uses and should be better tested in the wild

I see some additional compiler warning/error fixes in the nightly commit being used currently so not sure if it'll absolutely work.

(Just a suggestion as someone invested in getting this PR merged ASAP if the eigen maintainers are non responsive or non-committal to the questions posted)

[yurybura]

@ras0219-msft Thank you for your opinion. Please find my comments below.

• As stated by @BillyONeal, we need an understanding of why updating eigen implicates fmt (and vice versa). If we can update fmt without updating eigen, I'd really like to see that as a separate PR.

There have already been enough fmt update attempts that were unsuccessful: 1, 2, 3, 4, 5, 6, 7. There was also an attempt to update some dependencies: 1.

The update failures are due to the fact that there is no way to update important libraries and not update dependent libraries. I have encountered this many times when updating Boost. VCPKG contains many outdated libraries that are not supported by anyone, and the entire burden of supporting new versions falls on the one who updates the port in VCPKG.

An example from this PR is the shogun library. All CI checks are effectively disabled (=skip) and it doesn't even build anywhere except Linux. The library is effectively EOL, but is a blocker for Eigen3 update.

I think VCPKG should define a clear policy for EOL legacy ports.

• If we do need to update eigen to this unreleased version, skimming the patches makes me feel like it would be a smaller evil to add the <cassert> include back to eigen to make it more compatible with the current released version -- I count many ports that could be left untouched if we do that. Once eigen does a release, the ecosystem will start evolving to fix this on its own (as devs+distros pull the new version), which will reduce how much patching we need to do in the long run.

I thought about it. Most libraries that are regularly updated do not have such problems and do not need to be fixed. For others, I had the following options:

1. Patch Eigen3 to support legacy dependencies.
2. Patch legacy ports instead.

I chose the second option because:

1. Legacy libraries already contain many patches.
2. Having a questionable patch in Eigen3 can also lead to hiding bugs in dependent libraries and in the end user's code.

• Finally, I would prefer to see some of these picked apart into separate PRs where they stand alone. Those changes can be reviewed and merged asynchronously with this larger ball of yarn. That way they aren't held up nor hold up.

  • colmap's glew changes (port bug)
  • dartsim's treat_warnings_as_errors (this is already policy)
  • opencv2 using find_package()
  • etc

Many of these fixes were reproduced only with new versions of updated ports (new version of {fmt}, Eigen and etc.). Some minor fixes were quicker and more manageable to do right here because they blocked CI. I've already spent time investigating the issue, fixed it, and don't want to put it off or wait for a blocking new PR to be accepted. This probably makes the review a bit more difficult, but it's also worth considering the time of those who do the PR themselves.

When I saw such an opportunity, I did separate PRs: 1, 2.

[Shuenhoy]

Do I understand correctly?

Updating fmt will break some ports that depends on fmt, so that these ports must be also updated in the same PR. And some (which?) of these ports have already used the eigen unreleased version and cannot compile with the current eigen 3.4.0, therefore, eigen must be also updated in this PR. That is why eigen and fmt, which seems unrealted, are updated together here.

Off topic:

While I know it has been discussed, I think vcpkg should really start to reconsider a version "less" constraints or overrides in registry ports or something else. Otherwise, the maintaince burden might grow to an unfeasible point, and this PR is an example. The current "baseline" and "greater" constraints way also has its limitation in user side (You can use `version>=` to install a version greater than your baseline, but you can not use a port that does not exists in the baseline)

[yurybura]

Updating fmt will break some ports that depends on fmt, so that these ports must be also updated in the same PR.

Yes, that's pretty much how it works. You never know how far you'll have to go when updating a popular library.

Things got even more complicated after implementing a CI job to test feature combinations (see ci.feature.baseline.txt). CI looks green until you change something inside a library. Often after that you get a bunch of CI errors that were there before and have nothing to do with your changes..

[BillyONeal]

An example from this PR is the shogun library. All CI checks are effectively disabled (=skip) and it doesn't even build anywhere except Linux. The library is effectively EOL, but is a blocker for Eigen3 update.

Seems like a good reason to deindex the thing.

Updating fmt will break some ports that depends on fmt, so that these ports must be also updated in the same PR. And some (which?) of these ports have already used the eigen unreleased version and cannot compile with the current eigen 3.4.0, therefore, eigen must be also updated in this PR. That is why eigen and fmt, which seems unrealted, are updated together here.

The reason it isn't clear though is that neither eigen depends on fmt, nor fmt on eigen.

While I know it has been discussed, I think vcpkg should really start to reconsider a version "less" constraints or overrides in registry ports or something else.

This isn't a vcpkg rule, this is a C++ rule. The linker says you can only pick one, so any port with a hypothetical "less than" constraint prevents that dependency from ever getting updated in the registry again. We can't just drag in simultaneous versions of dependencies like ECMAscript/Python can.

[ankurvdev]

The reason it isn't clear though is that neither eigen depends on fmt, nor fmt on eigen.

I believe wpilib is the missing link. (If i'm following correctly here's the chain of dependency)

Updating fmt broke wpilib which necessitated either of the two options.

1. Patching older wpilib to work with newer fmt and keeping the version intact.
2. Updating wpilib which presumably included fixes to work with newer fmt (but also necessitated updating to newer eigen3)

And because option-2 was chosen this meant eigen3 needed to be updated as well (rather than wpilib patched to work with older eigen3)

[BillyONeal]

Updating fmt broke wpilib which necessitated either of the two options.

There is a third option: we are in this whole mess because wpilib is vendoring an unreleased copy of eigen. wpilib has not been updated in our registry in 2 years, which suggests very few people care. To @yurybura 's point about shogun, we can deindex the thing entirely.

@ras0219-msft (in person) points out that most all the changes in here are goodness regardless of whether we actually do the eigen update.

@yurybura How would you feel about keeping eigen at a release version, deindexing wpilib, and keeping your remaining changes?

[ras0219-msft]

goodness regardless of whether we actually do the eigen update.

minor rewording: I think that substantially all of the changes in this PR should eventually make it into the registry. I'd like it if we can defer the eigen update (and consequent fallout) until eigen officially releases.