Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow specifying FIND_SHARED_LIBS per-TPL #624

Merged
merged 3 commits into from
Feb 19, 2025

Conversation

sebrowne
Copy link
Contributor

Currently we (Trilinos) wish to be able to find all TPLs statically...except for some which we must find shared, because static installations do not exist in the environment we're using. For example, we want to use "all" static TPLs for our CUDA build, but the installation of METIS is only shared. Currently, this is done by setting TPL_FIND_SHARED_LIBS to OFF, and specifying METIS_LIBRARIES to be the explicit full path to libmetis.so. This unfortunately bypasses the 'finding' of METIS. It would be nicer if we could pass -DTPL_FIND_SHARED_LIBS=OFF -DMETIS_FIND_SHARED_LIBS=ON and have TriBITS continue to do the same thing for each TPL, by finding METIS as normal (eliminates some brittleness in our configuration management).

I looked at doing this, and the code change seems fairly trivial unless I'm missing something. I added a test as well.

@sebrowne
Copy link
Contributor Author

@bartlettroscoe no particular rush on this, but I'd appreciate a review whenever you have the time.

Copy link
Member

@bartlettroscoe bartlettroscoe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sebrowne, thanks for the PR. This is a very reasonable extension. And thanks for adding the test case! (If you revert the change to the *.cmake file, does the test fail? Hopefully yes but it is worth checking.)

Just a coupe of things should be addressed before merging:

  1. The logic for how the var ${TPL_NAME}_FIND_SHARED_LIBS is set should be tweaked (see below)
  2. This needs to be documented somehow. I might suggest adding a mention of this variable to the section Building static libraries and executables? (Or it could be a new subsection?)

@sebrowne
Copy link
Contributor Author

@bartlettroscoe applied your suggestion for 1., and added a blurb of documentation for 2.

Copy link
Member

@bartlettroscoe bartlettroscoe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great. Thanks!

@bartlettroscoe
Copy link
Member

FYI: The GHA checks are fixed in the PR #626. I will pull those checks off into their own PR and merge it so that it will allow this and other tests to pass.

@bartlettroscoe bartlettroscoe merged commit a3ddcf6 into TriBITSPub:master Feb 19, 2025
6 checks passed
@bartlettroscoe
Copy link
Member

@sebrowne, if urgent, I can setup snapshot/merge to Trilinos 'develop'. Otherwise, I will soon merge #626 and snapshot/merge TriBITS 'master' (including this PR) to Trilinos 'develop' in the next few days (after testing by the STK project).

@sebrowne
Copy link
Contributor Author

@sebrowne, if urgent, I can setup snapshot/merge to Trilinos 'develop'. Otherwise, I will soon merge #626 and snapshot/merge TriBITS 'master' (including this PR) to Trilinos 'develop' in the next few days (after testing by the STK project).

Waiting is a-okay with me, no rush. I'll start using it once it's in, but I can manage perfectly fine until then.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants