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

[BUG]: cuProj and cuSpatial are unnecessarily interdependent #1312

Open
harrism opened this issue Dec 7, 2023 · 1 comment
Open

[BUG]: cuProj and cuSpatial are unnecessarily interdependent #1312

harrism opened this issue Dec 7, 2023 · 1 comment
Assignees
Labels
bug Something isn't working

Comments

@harrism
Copy link
Member

harrism commented Dec 7, 2023

Version

24.02

On which installation method(s) does this occur?

Docker, Conda, Source, Rapids-Compose

Describe the issue

cuSpatial currently builds cuProj as part of its cmake, although they are supposed to be independent libraries. Also, cuProj tests and benchmarks include some cuSpatial files unnecessarily.

We should make them independent parts of a monorepo as much as possible.

Minimum reproducible example

No response

Relevant log output

No response

Environment details

No response

Other/Misc.

No response

@harrism harrism added the bug Something isn't working label Dec 7, 2023
@harrism harrism self-assigned this Dec 7, 2023
@harrism
Copy link
Member Author

harrism commented Aug 5, 2024

From @bdice in #1308:

@harrism I agree that there are varying degrees of scope that this could take. Let's limit the scope in this PR and restructure parts of dependencies.yaml but leave the rest of the refactor for another PR.

I think what I would propose for the second PR is:

  • Organize the C++ code to something like
cpp
 |--> cuspatial
         | - CMakeLists.txt
 |--> cuproj
         | - CMakeLists.txt
  • Consider adding a separate libcuproj package (with changes to build.sh, ci/build_cpp.sh, ci/build_python.sh, a new conda recipe, etc.)

libcuproj is header-only, so the conda package contents would be just headers (and it would define the build dependencies for those headers), like for rmm. It's also fine for us to just not have a libcuproj package and instead build the C++ code in the cuproj Python build steps, but the problem is really that libcuproj tests/benchmarks are being lumped with libcuspatial's build process, as far as I can tell. The need to isolate tests/benchmarks are enough for me to vote in favor of a separate conda package. I would still advocate for the C++ file organization above, either way.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: In Progress
Development

No branches or pull requests

1 participant