Skip to content

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

Open
wants to merge 1 commit into
base: branch-25.08
Choose a base branch
from

Conversation

mostroot
Copy link

@mostroot mostroot commented Jul 7, 2025

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:

  1. Build cuOpt
  2. Navigate to cpp/build
  3. run cpack -G DEB

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 and cuOpt_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 directory
The .so files are installed in the /usr/local/lib directory

The 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

  • I am familiar with the Contributing Guidelines.
  • Testing
    • New or existing tests cover these changes (Not added for the cmake changes)
    • Added tests (Compiling and deb installation works, unsure how you'd like a test for this)
    • Created an issue to follow-up
    • NA
  • Documentation
    • The documentation is up to date with these changes
    • Added new documentation ( Happy to add the documentation just need to pointed to where you'd like the cpack instructions)
    • NA

@mostroot mostroot requested review from a team as code owners July 7, 2025 22:08
@mostroot mostroot requested review from Iroy30 and bdice July 7, 2025 22:08
Copy link

copy-pr-bot bot commented Jul 7, 2025

This pull request requires additional validation before any workflows can run on NVIDIA's runners.

Pull request vetters can view their responsibilities here.

Contributors can view more details about this message here.

@rg20 rg20 assigned rgsl888prabhu and unassigned rgsl888prabhu Jul 8, 2025
@rg20 rg20 requested a review from rgsl888prabhu July 8, 2025 13:19
@rgsl888prabhu
Copy link
Collaborator

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.

@mostroot
Copy link
Author

mostroot commented Jul 8, 2025

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.

@mostroot
Copy link
Author

mostroot commented Jul 9, 2025

@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: cuda-toolkit-12-1 or cuda-toolkit-12-8 cpack sees those as two completely different package names, not two versions of the same name. So I could set very strict requirements of a particular version like 12-8, but it wouldn't be installable on any system with another version of cuda-toolkit installed.

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 :)

@rgsl888prabhu
Copy link
Collaborator

rgsl888prabhu commented Jul 11, 2025

@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: cuda-toolkit-12-1 or cuda-toolkit-12-8 cpack sees those as two completely different package names, not two versions of the same name. So I could set very strict requirements of a particular version like 12-8, but it wouldn't be installable on any system with another version of cuda-toolkit installed.

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.

@vyasr
Copy link

vyasr commented Jul 14, 2025

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.

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.

@rgsl888prabhu
Copy link
Collaborator

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.

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.

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.

3 participants