-
Notifications
You must be signed in to change notification settings - Fork 50
Feat: rework cmakelists.txt to facilitate deb file creation. #190
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
base: branch-25.08
Are you sure you want to change the base?
Conversation
Thank you @mostroot for the issue and the PR, I wanted to understand the use case of deb package compared to pip wheel. And also do we expect underlying dependencies to be available as deb package or expect users to install it by themselves. As per my knowledge, there few dependencies which are header only, but there are dependencies which are in the form of conda or pip wheel package. So, we might not have all dependencies available as .deb package. |
From my testing, all of the dependencies are mostly contained in rapids and the base cuda instalation. I'll see what I can do to get the dependencies behaving via the deb route. As far as the Usecase, it enables other packages like SimpleRose's solver to depend on the cuOpt deb package. We plan on self hosting a latest version of cuopt privately. It fits in with our existing stack being entirely installable via deb packages. This just provides a very scalable way to install on a distributed network of instances essentially. The pip wheel route could work for us, but would require some scripting instead of existing deb package dependency linking. |
@rgsl888prabhu I looked into the dependency tracking for the deb file, in short its rather complicated. I can specify that it depends on a particular cuda-toolkit version in the file, but because of how the Nvidia cuda-toolkit versions are packaged I can't do something simple like: depends on cuda version 11 or greater. In short the cuda-toolkit's are literally named: Because of this, I think the right route is to have this produce a deb file with no dependencies and assume that the user has cuda and the cuda-toolkit installed correctly. It's not perfect, a user could add specific dependencies for a particular version if they wanted their deployed systems to function correctly, or alternitively you could have a lengthy script that creates a ton of different deb files for each specific version of cuda and let the user pick the right one. I could take a stab at that solution, but I think it would be much more messy. Happy to find some time to talk through it if you'd like. Let me know where you'd like me to take it. Also @rgsl888prabhu that's a great one piece avatar you have :) |
Thank you @mostroot for detailed findings, as of now we haven't had a particular request to maintain deb package from the community. And leaving dependency installation always raises more questions and issues. But I will discuss with team whether we can enable this as one more option through source code as independent lib without any dependencies, and advanced users like you can explore how you want to integrate it. But I would also suggest you to take a look at integrating pip package since it would help with dependency and it would be easier to also install any new night-lies or releases. : ) I am an OTAKU and like to watch Anime and Read Manga. |
We don't have debs for the rest of RAPIDS either. There are discussions around moving in that direction in rapidsai/build-planning#45. If the cuopt team decides to move forward here, it would be ideal to find solutions that are reusable across other libraries too. |
Thank you @vyasr. |
Description
Adds changes to the top level cmake_lists.txt to enable cpack creation of .deb files. In order to create the runtime and develop .deb files you will need to:
This creates two .deb files for the architecture of the machine that cuOpt is built on.
For example:
cuOpt_25.08.0_amd64-Development.deb
andcuOpt_25.08.0_amd64-Runtime.deb
The runtime deb package contains the cuopt CLI, the mps reader.so and the cuopt.so.
The cuopt_CLI is installed in the
/usr/local/bin
directoryThe .so files are installed in the
/usr/local/lib
directoryThe development deb package contains the mps reader.so, the cuopt.so and the header files for the project all of which are installed in
/usr/local/lib
in a standard fashion.The headers are in
/usr/local/lib/cuopt
Note: There are items in the deb package creation that I took the liberty to fill, some of them may need changes.
Specifically these two lines:
set(CPACK_DEBIAN_DEV_PACKAGE_MAINTAINER "NVIDIA")
set(CPACK_DEBIAN_RUNTIME_PACKAGE_MAINTAINER "NVIDIA")
I assumed that is how you'd like the maintainer referenced.
Additionally the deb packages do not correctly reference their dependencies yet, i'm happy to follow up with that work if this looks likely to be merged.
Issue
#189
Checklist