-
Notifications
You must be signed in to change notification settings - Fork 163
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
Allow installing components when downstream #2096
Allow installing components when downstream #2096
Conversation
a1e076c
to
81d4875
Compare
Maybe @alliepiper can help here. |
@alliepiper @robertmaynard could you take a look at this? |
Can you update the message to say this resolves #1205 |
/ok to test |
81d4875
to
e423002
Compare
In the @acts-project we adopt an (admittedly somewhat unconventional) build system in which software A depends on B, and B depends on CCCL. The setup is that we want to install B into a prefix, and then try to build A against B. The problem arises is that we are using CMake to dynamically fetch CCCL using the so-called "FetchContent" mechanism, which downloads CCCL and then adds it as a subdirectory. The core problem is that installing software B which has included CCCL does not actually install CCCL in the same prefix, so software A cannot then load software B as CCCL is not installed. The reason this happens is that CMakeLists.txt:28 (at the time of writing) returns from the CMake configuration stage early, and leaves the CUB, Thrust, and libcudacxx directories unincluded (see lines 70 to 72). Although this is, again, an unconventional and rare scenario, it should be easy to add support for this kind of build, and I hope the CCCL devs would agree that it might be worth doing. In this commit, I remove the early return and replace it with additional if-statements. This commit should leave any existing workflows completely untouched, but should make it easier to use CCCL in the way we do in @acts-project.
I have removed the condition include of CTest, as it seemed to be causing some problems. |
🟨 CI finished in 8h 18m: Pass: 83%/421 | Total: 1d 13h | Avg: 5m 21s | Max: 1h 05m | Hits: 95%/474855
|
Project | |
---|---|
+/- | CCCL Infrastructure |
libcu++ | |
CUB | |
Thrust | |
CUDA Experimental | |
pycuda |
Modifications in project or dependencies?
Project | |
---|---|
+/- | CCCL Infrastructure |
+/- | libcu++ |
+/- | CUB |
+/- | Thrust |
+/- | CUDA Experimental |
+/- | pycuda |
🏃 Runner counts (total jobs: 421)
# | Runner |
---|---|
305 | linux-amd64-cpu16 |
65 | linux-amd64-gpu-v100-latest-1 |
28 | linux-arm64-cpu16 |
23 | windows-amd64-cpu16 |
/ok to test |
🟨 CI finished in 3h 08m: Pass: 99%/421 | Total: 1d 22h | Avg: 6m 37s | Max: 1h 01m | Hits: 98%/524399
|
Project | |
---|---|
+/- | CCCL Infrastructure |
libcu++ | |
CUB | |
Thrust | |
CUDA Experimental | |
pycuda |
Modifications in project or dependencies?
Project | |
---|---|
+/- | CCCL Infrastructure |
+/- | libcu++ |
+/- | CUB |
+/- | Thrust |
+/- | CUDA Experimental |
+/- | pycuda |
🏃 Runner counts (total jobs: 421)
# | Runner |
---|---|
305 | linux-amd64-cpu16 |
65 | linux-amd64-gpu-v100-latest-1 |
28 | linux-arm64-cpu16 |
23 | windows-amd64-cpu16 |
Alright, that looks better! I hadn't expected that conditionally loading CTest would break the CI though; seems counter-intuitive but might be by design. |
Struggling to tell if the CI failure is related; also I'm a new contributor so I am not sure if 100% success rate is expected or if you see occasional transient failures? |
🟩 CI finished in 4d 05h: Pass: 100%/421 | Total: 1d 23h | Avg: 6m 47s | Max: 1h 14m | Hits: 98%/525266
|
Project | |
---|---|
+/- | CCCL Infrastructure |
libcu++ | |
CUB | |
Thrust | |
CUDA Experimental | |
pycuda |
Modifications in project or dependencies?
Project | |
---|---|
+/- | CCCL Infrastructure |
+/- | libcu++ |
+/- | CUB |
+/- | Thrust |
+/- | CUDA Experimental |
+/- | pycuda |
🏃 Runner counts (total jobs: 421)
# | Runner |
---|---|
305 | linux-amd64-cpu16 |
65 | linux-amd64-gpu-v100-latest-1 |
28 | linux-arm64-cpu16 |
23 | windows-amd64-cpu16 |
In the @acts-project we adopt an (admittedly somewhat unconventional) build system in which software A depends on B, and B depends on CCCL. The setup is that we want to install B into a prefix, and then try to build A against B. The problem arises is that we are using CMake to dynamically fetch CCCL using the so-called "FetchContent" mechanism, which downloads CCCL and then adds it as a subdirectory. The core problem is that installing software B which has included CCCL does not actually install CCCL in the same prefix, so software A cannot then load software B as CCCL is not installed. The reason this happens is that CMakeLists.txt:28 (at the time of writing) returns from the CMake configuration stage early, and leaves the CUB, Thrust, and libcudacxx directories unincluded (see lines 70 to 72). Although this is, again, an unconventional and rare scenario, it should be easy to add support for this kind of build, and I hope the CCCL devs would agree that it might be worth doing. In this commit, I remove the early return and replace it with additional if-statements. This commit should leave any existing workflows completely untouched, but should make it easier to use CCCL in the way we do in @acts-project.
resolves #1205
In the @acts-project we adopt an (admittedly somewhat unconventional) build system in which software A depends on B, and B depends on CCCL. The setup is that we want to install B into a prefix, and then try to build A against B. The problem arises is that we are using CMake to dynamically fetch CCCL using the so-called "FetchContent" mechanism, which downloads CCCL and then adds it as a subdirectory.
The core problem is that installing software B which has included CCCL does not actually install CCCL in the same prefix, so software A cannot then load software B as CCCL is not installed. The reason this happens is that CMakeLists.txt:28 (at the time of writing) returns from the CMake configuration stage early, and leaves the CUB, Thrust, and libcudacxx directories unincluded (see lines 70 to 72).
Although this is, again, an unconventional and rare scenario, it should be easy to add support for this kind of build, and I hope the CCCL devs would agree that it might be worth doing. In this commit, I remove the early return and replace it with additional if-statements. This commit should leave any existing workflows completely untouched, but should make it easier to use CCCL in the way we do in @acts-project.
Resolves #1205.