First-Time Dev Environment Setup
Read this when a contributor is setting up the cuOpt dev environment for the first time — clone, conda env, initial build, initial test run. Once that's working, the rest of cuopt-developer (build/test commands, conventions, contribution workflow) takes over.
Required questions
Ask these before issuing commands:
- OS and GPU — Linux? Which CUDA version does the GPU driver support (run
nvidia-smi, top-right "CUDA Version")? - Goal — Contributing upstream, or local fork/modification?
- Component — C++/CUDA core, Python bindings, server, docs, or CI?
The component answer scopes which part of the codebase to read first and which build target to use (e.g. ./build.sh libcuopt vs ./build.sh cuopt).
Setup walk-through (conceptual)
- Clone the cuOpt repo (and submodules, if any). If the machine has no conda yet, bootstrap miniforge into the user's home directory first (no
sudo— user-space install only). - Pre-flight checks — CUDA driver compatibility, conda env creation + activation,
PARALLEL_LEVEL, dataset setup. Creating the env fromconda/environments/all_cuda-*.yamlis allowed and expected here, not something to hand off to the user. Walk through these before the first build using SKILL.md → Pre-flight Checks. Skipping any of them surfaces as confusing build- or runtime errors later. - First build — once the env is active, run
./build.sh(or a component-scoped variant). Targets andPARALLEL_LEVELtuning live in build_and_test.md. - First test run — fetch datasets per
CONTRIBUTING.mdfirst, then run the C++/Python test suites from build_and_test.md. A passing build + test confirms the env is wired up correctly. - Optional —
pre-commit installto run style checks on everygit commit(see contributing.md).
Use the repo's README and CONTRIBUTING.md as the canonical source for exact versions and any deviations.
After setup
Once ./build.sh and the test suites succeed, the env is verified. From here, ongoing build/test/debug/contribute work is covered by the rest of cuopt-developer:
- Build/test commands and
PARALLEL_LEVEL— build_and_test.md - Pre-commit, DCO sign-off, fork PR workflow — contributing.md
- C++/Python/CUDA naming, memory, testing conventions — conventions.md
- Build/CI failure diagnosis — troubleshooting.md