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

Make all executables in example directories installable? #593

Open
cgcgcg opened this issue Aug 2, 2023 · 3 comments
Open

Make all executables in example directories installable? #593

cgcgcg opened this issue Aug 2, 2023 · 3 comments

Comments

@cgcgcg
Copy link

cgcgcg commented Aug 2, 2023

Trilinos/MueLu (and I think Trilinos in general) is not really using the INSTALLABLE flag for executable targets a whole lot. It would be nice to directly get more executables when installing for example using spack. We could go through and add this to a bunch of our executables by hand.

I was wondering whether it would be possible (and make sense) to instead switch the default behavior of tribits_add_executable for all executables in folders that have been added using tribits_add_example_directories. Or maybe add an option to tribits_add_example_directories that allows to switch the default behavior.

@bartlettroscoe
Copy link
Member

CC: @jwillenbring, @sebrowne, @mmwolf

@cgcgcg, what would be the value of installing binary example executables, for example, with Spack? Without the ability to rebuild from source, what value is an installed naked binary example executable? Also, many of the examples need access to input files, and if those are not installed as well, then you can't run the executables. And even if you install the input files, what about the other arguments so they run the example executable correctly? So just installing all binary example executables is likely to confuse and frustrate users when they can't run them correctly.

What would be of more value, IMHO, is actually installing source code, the input files, and a CMake file that can be used to build and run (with CTest and pass/fail testing criteria) the example(s) which calls find_packag(MueLu) (or whatever the package may be). That is what I did years ago for Thyra (pre-CMake) which you can see here. It would not be too hard to install these little external CMake projects that users can then build and run examples so that the user could modify and rebuild. But they would need to be constructed in a custom fashion to be useful. And there would need to be set up some automated testing to make sure these installed examples ran correctly. (That could be done using the TrilinosInstallTests package if we define standards for what these installed example CMake projects look like.)

This is something we need to bring before the Trilinos developers and find finding to support.

@cgcgcg
Copy link
Author

cgcgcg commented Aug 2, 2023

what would be the value of installing binary example executables, for example, with Spack? Without the ability to rebuild from source, what value is an installed naked binary example executable?

Not sure I understand the point you're trying to make. If a user wants to try out our driver that loads a matrix&rhs from file and solves the system using AMG, they encounter issues when using spack. (They could keep the build dir around, but that's a bit clunky.)

Also, many of the examples need access to input files, and if those are not installed as well, then you can't run the executables. And even if you install the input files, what about the other arguments so they run the example executable correctly?

Good point about input files and command line args.

This is something we need to bring before the Trilinos developers and find finding to support.

Yeah, I wanted to gauge first what kind of issues we'd encounter or if there already is a better solution.

@bartlettroscoe
Copy link
Member

@cgcgcg, if you want this taken up, we should probably create a Trilinos Framework backlog issue. Can you access the Trilinos Helpdesk at:

?

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

No branches or pull requests

2 participants