[fmt] update to v11.2.0, [eigen] update to v3.4.90-20250425211352-729443409942, [fcl] update to v0.7.0-20250313155144-a3fbc9fe4f61, [wpi] update to v2025.3.2, fix issues in dependent ports

[yurybura]

• 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.
• Any fixed CI baseline entries are removed from that file.
• Any patches that are no longer applied are deleted from the port's directory.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is added to each modified port's versions file.

Fixes #39856
Fixes #42927
Fixes #43106
Fixes #43548
Fixes #44042
Fixes #45047
Fixes #45357

[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.

[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.

[yurybura]

@BillyONeal, @ras0219-msft Thank you for your review.

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

Okay, I'll take care of it.

FYI. Eigen release plans have changed. Next milestone is 5.0.

[BurningEnlightenment]

FYI. Eigen release plans have changed. Next milestone is 5.0.

Do you happen to know the rationale? Is it due to the Bazel Central fuck-up?

[yurybura]

FYI. Eigen release plans have changed. Next milestone is 5.0.

Do you happen to know the rationale? Is it due to the Bazel Central fuck-up?

Unfortunately, I don't know. But the progress is pretty good - 99%). That would be the best option to switch to a new release.

[alxvth]

I have no personal insights into the changes, but this is from a discussion on the Eigen Discord:

Technically it's 3.5.0.0, but we'll be dropping the "world" version from the release number.
Eigen release numbers were historically WORLD.MAJOR.MINOR instead of the standard MAJOR.MINOR.PATCH. Though the WORLD version only changed once.

A user posted this table for clarification:

Release	3.4	5.0
WORLD	3	3
MAJOR	4	5
MINOR	0	0
PATCH	-	0

[sixme]

Any update on this? It seems that everything is green finally! Just some merge conflicts?

[dg0yt]

There are controversial topics which need to be resolved.
In particular there is the lack of an eigen3 release.

And there are a number changes which are hardly connected to the original topic (fmt) at all. I started pulling some of them out today, as suggested before.