[eigen3] update to 3.4.1-250818 from 3.4.0

[alxvth]

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

This PR updates eigen to the most recent commit (from Aug 18, 2025 as of Aug 20, 2025) of the 3.4 branch which indicates version 3.4.1 in Eigen/src/Core/util/Macros.h.
There is no 3.4.1 tag upstream, but the version was updated in this commit from Nov 5, 2023, see also the discussion below.

The previous patches are all upstream and removed in this PR:

• fix-vectorized-reductions-half.patch in b0fe14213ec4c8615de485fe4c2bcd4bab0cbd19
• remove_configure_checks.patch in f1922b6dac4a9c18b07c26658cea08db80489278
• update-warning-suppression-to-latest.patch in 34e5f34b391e9b964917d54139aae1ecf522d4e5

The portfile.cmake changes are mainly the same as in #45295.

Full diff log: 3.4.0...cd7263e7f626e75c9210b74d2d6043a8c0519f1c

[alxvth]

@microsoft-github-policy-service agree

[dg0yt]

Is this meant as a draft?

Once there is a 3.4.1 release:

[alxvth]

Is this meant as a draft?

Once there is a 3.4.1 release:

Ah yes, that's a better idea!

[alxvth]

There seems to be some motion upstream to finally tag a new release.

The latest commit on the 3.4 branch now actually defines the version as 3.4.1.
That branch did actually not do that yet on the commit I was referring to in this PR. (There used to be a 3.4.1 branch, which apparently was deleted in the meantime).
It might be better to use the most recent commit to the 3.4 branch for 3.4.1 here. What do you think?

Meanwhile, the master defines the version as 3.4.90.

[BillyONeal]

Closed and reopened because GitHub was stuck

[BillyONeal]

The latest commit on the 3.4 branch now actually defines the version as 3.4.1.
That branch did actually not do that yet on the commit I was referring to in this PR. (There used to be a 3.4.1 branch, which apparently was deleted in the meantime).

If upstream has officially declared another commit as what is actually 3.4.1 then indeed we would want that to be the one we deploy claiming to be that version. As a result I cancelled PR build because the lab is very behind right now.

Meanwhile, the master defines the version as 3.4.90.

That one is up to you; there's nothing wrong with taking the smaller version update and doing a separate PR with a current one.

[Neumann-A]

X.Y.9Z versions are in some world just dev versions. Another example already observed in vcpkg with that versioning was either fontconfig or freetypein the past

[alxvth]

Over the last years there have been multiple requests for tagging a new release upstream, but so far nothing came of it:
libeigen/eigen#2699 (Jul 2023), libeigen/eigen#2702 (Jul 2023), libeigen/eigen#2724 (Oct 2023), libeigen/eigen#2809 (Apr 2024), libeigen/eigen#2845 (Aug 2024), libeigen/eigen#2848 (Aug 2024), libeigen/eigen#2879 (Nov 2024), libeigen/eigen#2907 (Feb 2025).

In one of these threads (#2879) a maintainer recommends (mostly) using the latest commit (from master) that passes all their test. Now, one of the many changes between the 3.4 branch and the current upstream master is the minimum required c++ version (c++14 vs c++03). It would be great to list one version of eigen in vcpkg that contains the by now 200+ build and runtime fix commits from the 3.4 branch since the 3.4.0 tag, before (at some point hopefully) moving closer to the master branch.

The most recent changes to the 3.4 branch in the previous six months were either CI fixes or upstream-merges of patches that I wrote for this PR. It seems fair to say that the branch is rather stable and the latest commit on it a good candidate for indexing here.

I appended the date of the commit I'm using for this PR to the version to indicate that it's not an official tag.

[alxvth]

Also relevant:

• eigen: Add 3.4.90-unstable version conan-io/conan-center-index#28205
• a list of how other package repositories handle requests like this PR, from one of the discussions mentioned above: libeigen/eigen#2907#note_2687977253

[dg0yt]

❤️
LGTM, but somebody else must approve.

[alxvth]

@BillyONeal What do you think about this update?

[alxvth]

Nice, thanks!