Set Trilinos_MUST_FIND_ALL_TPL_LIBS=TRUE by default for Trilinos 15.0

[bartlettroscoe]

@trilinos/framework

With Trilinos 14.0 coming up, this would be a good time to change the default for Trilinos_MUST_FIND_ALL_TPL_LIBS from OFF to ON. (By setting Trilinos_MUST_FIND_ALL_TPL_LIBS_DEFAULT to ON as described here). It was turned off by default because it breaks backward compatibility but it causes problems for new users and new configurations (see, for example, #10322 (comment)).

So as soon as the Trilinos 13.4 branch is created, we should make this change in the 'develop' branch.

[bartlettroscoe]

@ccober6, would it be possible to create GitHub Issue Milestone for Trilinos 14.0 so that we can place this and other issues like it to remind us to do these things for Trilinos 14.0?

[github-actions]

This issue has had no activity for 365 days and is marked for closure. It will be closed after an additional 30 days of inactivity.
If you would like to keep this issue open please add a comment and/or remove the MARKED_FOR_CLOSURE label.
If this issue should be kept open even with no activity beyond the time limits you can add the label DO_NOT_AUTOCLOSE.
If it is ok for this issue to be closed, feel free to go ahead and close it. Please do not add any comments or change any labels or otherwise touch this issue unless your intention is to reset the inactivity counter for an additional year.

[jwillenbring]

Was this done, or is this still of interest?

[ccober6]

Hmm... We may have just missed this. @sebrowne

[sebrowne]

I missed it for sure. We can add it to the 14.0.1 release (I think that @hkthorn said that Xyce needs one, see #11685 )

Do we want it added to the 14.0 release, or just change it on develop so that it occurs in post-14.0 releases?

[ccober6]

I am in favor of getting it in 14.0.1 and develop, so long as it doesn't cause stakeholders a headache. They have not had any notice of this. If it causes backward incompatibilities we will need to wait until Trilinos 15.0 (~Sept 2023).

[bartlettroscoe]

This will definitely break backward compatibility but likely in a good way 90% of the time. And users that don't want this behavior can just set -D Trilinos_MUST_FIND_ALL_TPL_LIBS=OFF (which is backward compatible).

Also, if I had realized that the Trilinos 14.0 release was immanent, I would have made sure and merge:

• Complete initial implementation for treating internal packages as external found with find_package() (#63) TriBITSPub/TriBITS#560
• Tweaks to Trilinos to get working with pre-installed Kokkos and KokkosKernels (with TriBITS updates) (#11545) #11546

because that might technically break backward compatibility in some corner cases.

[bartlettroscoe]

FYI, the conversation about backward compatibility seems to have evolved over the last few years. Now semver seems to differentiate "major" and "minor" breaks in backward compatibility and incrementing the major version number. For example, see:

• https://semver.org/#what-if-i-inadvertently-alter-the-public-api-in-a-way-that-is-not-compliant-with-the-version-number-change-ie-the-code-incorrectly-introduces-a-major-breaking-change-in-a-patch-release

If a single configure option can restore backward compatibility and if the change is backward compatibility is obvious, then I think that should not warrant an increment of the major version number.

In order words, I think changing the default of Trilinos_MUST_FIND_ALL_TPL_LIBS from OFF to ON should be okay in a patch release (also since most customers will not touch an X.Y.0 release and will wait for the X.Y.1 release before trying to use it).

Up to this point, very good backward compatibility is maintained for customers my setting a few configure options.

[ccober6]

@bartlettroscoe if you are comfortable with us patching 14.0 and merging to develop, I would say let's give it try and if we run into issues we can back it out.

@sebrowne, we should create a Trilinos 15.0 issue and link issues related to the release to help include issues like this with 15.

[bartlettroscoe]

@sebrowne, @ccober6, let's not forget to do this after Trilinos 14.4 is branched!

[bartlettroscoe]

@sebrowne and @ccober6, I created the GitHub Issue milestone trilinos-15.0 to help remind people of what needs to be done before the Trilinos 15.0 release.

[sebrowne]

Thanks Ross! I'm all in favor of putting this in ASAP after we get 14.4 out the door (should be very soon).

[sebrowne]

@bartlettroscoe do you want me to do this now that 14.4 is out?

[bartlettroscoe]

@bartlettroscoe do you want me to do this now that 14.4 is out?

Yes, but we will need to write a release note for this. And this may break some customer's configure scripts because they may have had extra libs they did not need that did not get found but it happened to work anyway.

[srbdev]

@bartlettroscoe should I make the change under cmake/tribits/core/package_arch/TribitsGlobalMacros.cmake on line 568 or should it only be made specific to Trilinos, with the Trilinos_ prefix?

[bartlettroscoe]

@bartlettroscoe should I make the change under cmake/tribits/core/package_arch/TribitsGlobalMacros.cmake on line 568 or should it only be made specific to Trilinos, with the Trilinos_ prefix?

No, see:

• https://tribitspub.github.io/TriBITS/users_guide/index.html#project-name-must-find-all-tpl-libs

Setting this in the CMakeLists.txt file makes more sense since this does not impact the dependency logic.

[bartlettroscoe]

With the merging of #12258, this should be complete. (But someone should have done a local build to ensure this is working to catch non-found libraries.)

[bartlettroscoe]

This was completed with the merge of PR:

• Famework: Change defaults for Trilinos-specific CMake flags #12258