Improve packageability of install and install gdb pretty-printer#1502
Conversation
pratikvn
left a comment
There was a problem hiding this comment.
I thought you also wanted to install the benchmark related files ?
yhmtsai
left a comment
There was a problem hiding this comment.
Runtime is only used in runtime linking, right?
Users will only use them with some pre-built packages.
MarcelKoch
left a comment
There was a problem hiding this comment.
Would this be a good opportunity to also fix the cmake --install . --prefix some/prefix/path behavior? Right now, the --prefix path is just ignored.
|
@MarcelKoch I think this is a bigger can of works I'd like to avoid opening right now. There are a few places where we contain absolute paths instead of ones relative to At the very least, we'd need to revert parts of #1325 |
|
@upsj Ok, I just wanted to check that. Since I'm the only one complaining about it, I will look into it. |
- install symlinks only for development (NAMELINK_COMPONENT) - better formatting Co-authored-by: Pratik Nayak <pratik.nayak@kit.edu>
909999c to
fda7259
Compare
|
@pratikvn Installing benchmarks is much more complicated, since it requires installing things like gflags and our timer/linop wrapper libraries. I'll leave that for a subsequent PR |
Couldn't we just depend on a package manager (spack, conan, pacman, ...) to first install gflags as most other packages do? And if that was not the case, fail loudly. I don't think we need to change that much, and I don't think it's unreasonable to ask people to install that package if they really want the benchmarks to be installed. It does require an option to separately install dev tools/support compared to the core. |
|
@tcojean We can avoid separate options by marking the |
|
@upsj You mentioned "auto-load safe-path" in #1502 (comment) but the Indeed, most Arch Linux packages install gdb scripts in Would you consider changing this or making it configurable in ginkgo? |
|
Good point, there are two possible approaches we could take: 1. make the path configurable in CMake or 2. move the pretty-printer to a separate install component like Ginkgo_PrettyPrinter. That would allow you to install it with a different prefix. I would probably prefer the latter, since it is easier to implement, and both solution come with little additional work for the packager. What do you think?
|
|
Hmm does cmake allow to easily install all except one specific components? AFAIK, it can either install everything or one component at a time. This would require me to loop over all components during install... |
|
There are two components only, one to build a runtime package, one a development package. If you don‘t have have the same package separation, are three separate calls manageable? Otherwise we can consider the CMake variable approach.
|
|
It is manageable atm, but I'd have to watch out for the future components 😄 I still like the cmake variable more, it allows to keep the script in the current component and location by default without breaking the expectations of everybody else. |
To make packaging Ginkgo easier, we can separate the installable components into
DevelopementandRuntime(imagine libginkgo and libginkgo-dev packages). By default all packages get installed (we can control this usingEXCLUDE_FROM_ALL), but you can choose individual components separately.For some more context, look at https://www.youtube.com/watch?v=m0DwB4OvDXk around 30:00
Related content: https://www.youtube.com/watch?v=sBP17HQAQjk https://www.youtube.com/watch?v=_5weX5mx8hc
Also I noticed that the compiler version check doesn't check whether a language is enabled, so if CUDA is not enabled, it complains about us using the wrong CUDA compiler.
Finally, every time a shared library gets loaded, gdb looks for
libsomething.so.x.x.x-gdb.pyfiles in its auto-load safe-path. We can use this to make our pretty-printer available to user debug builds.