Update to newer eigen when available

[jhlegarreta]

Description

Warnings related to unused eigen symbols are being reported since a while on some of the platforms builds, e.g.
https://open.cdash.org/viewBuildError.php?type=1&buildid=8095196

All RogueResearch sites, which use Apple Clang, show these build warnings.

Steps to Reproduce

1. Download ITK
2. Configure
3. Build using Apple Clang

Expected behavior

No warnings are present when building ITK.

Actual behavior

A few build warnings are reported when compiling ITK with Apple Clang.

Reproducibility

%100

Versions

ITK master.

Environment

OS: macOS (different versions: 10.x, 11, 12)
CMake: (?)
Compiler: Apple Clang

Additional Information

Related to: 9d9b416

The MR https://gitlab.com/libeigen/eigen/-/merge_requests/864 related to the referenced issue https://gitlab.com/libeigen/eigen/-/issues/2416 was merged to eigen master on March, 3 2022

Last eigen update in ITK: #3133 (eigen 3.4).

Unfortunately, there hasn't been yet a new release since then (August 18, 2021)

[jhlegarreta]

CC @seanm @phcerdan

[jhlegarreta]

Relevant information:
https://gitlab.com/libeigen/eigen/-/milestones
https://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2021/09/msg00000.html

[seanm]

Those eigen warnings are still on cdash. IIRC I fixed some of them upstream in eigen itself.

It looks like their last release is still 3.4 from 2021: https://gitlab.com/libeigen/eigen/-/releases

I found a ticket pushing for a new release: https://gitlab.com/libeigen/eigen/-/issues/2699

[jhlegarreta]

Thanks for the follow-up Sean. It looks like the library gets commits regularly; not sure why no new releases have been cut.

[phcerdan]

Given the lack of Eigen releases, another option is to update ITK to use Eigen master (we ping/freeze the commit we use). This would be a major upgrade of Eigen, but we don't have much code using it, and we don't use any fancy feature, so it's doable to keep up to date with upstream.

This way we can also fix warning upstream rapidly. Now, we have to backport them to 3.4.

[seanm]

@phcerdan sounds like a good plan to me. Is someone familiar with syncing to eigen?

[phcerdan]

I can help with that, I will open PR next week.

[phcerdan]

Opened PR #4265 updating to eigen master.
Hitting long-existing issue when updating ThirdParty modules, but I think the update went well, but still work in progress.

[phcerdan]

@N-Dekker realized that there is a 3.4.1 branch in #4265.

It seems promising, maybe they are working on a new release. The current last release was from years ago.

Not sure, good to discuss what we prefer, master or this 3.4.1 branch.

I tend to prefer master, living at the head philosophy. It might be a bit bumpy at the start, but we can solve our warnings way faster this way.

But beyond that, I am open to whatever we decide! Pinging @seanm @thewtex @jhlegarreta @dzenanz.

[N-Dekker]

In general, I'm in favor of using a tagged version (of any library), as it is usually more stable, more carefully maintained, tested, and documented than just any arbitrary revision from the main/master branch. So I don't really embrace that so-called "living at the head philosophy". Maybe for experimental software, but not for a stable ITK release. What do you think?

PS If there is a specific reason for a specific third party library to use a particular revision from its commit history, instead of a tagged version, of course, I can understand that, as an exception to the rule.

[seanm]

In general I also prefer a tagged release, with the hope/idea being that the project has done some QA and polish before giving it a formal tag.

But the eigen project does not seem to work this way. 2+ years with no release at all.

How much work is it to update eigen in ITK? If small, we could go to tip of the 3.4.1 branch first, digest that, then go to master (which I suspect would be necessary honestly).

I've just asked about the state of master here: https://gitlab.com/libeigen/eigen/-/issues/2699

[phcerdan]

Great question upstream @seanm. Let's see their answer! Eigen is header-only, and we only pull the core subset in our third-party updates.

[jhlegarreta]

I prefer a tagged version, but given the circumstances I ignore the benefit of going towards 3.4.1 over the current tip (besides concerns about the leap to the current tip being too much): we have no guarantee that 3.4.1 will be made into a tag.