camp isn't exporting BLT HIP targets

[cyrush]

Camp + HIP doesn't export blt's hip cmake targets, so folks downstream using cmake but not using blt can't compile.

I started my adventure with this problem in an Ascent issue - please see full details there: Alpine-DAV/ascent#982

For prior releases of RAJA -- we were using built-in camp, but now that we are using a separate camp build for associated 2022.03 releases, this is a blocker for enabling RAJA+HIP in Ascent.

I am happy to help fix and test this.

[trws]

The prerelease on main should be exporting those targets as if a couple of days ago, as part of the ongoing massive rework to unbreak BLT target export across the raja suite. The raja updates are currently sitting in a PR, but all of it should land as soon as the umpire update is through testing, hopefully tomorrow. Testing with the updates would be greatly appreciated actually, we uncovered bugs or issues in something like 7 repositories and packages trying to root all of this out.

…

--- Sent from Workspace ONE Boxer<https://whatisworkspaceone.com/boxer> On August 4, 2022 at 7:02:05 PM PDT, Cyrus Harrison ***@***.***> wrote: Camp + HIP doesn't export blt's hip cmake targets, so folks downstream using cmake but not using blt can't compile. I started my adventure with this problem in an Ascent issue - please see full details there: Alpine-DAV/ascent#982<https://urldefense.us/v3/__https://github.com/Alpine-DAV/ascent/issues/982__;!!G2kpM7uM-TzIFchu!g2CjKFREf2lPazYosZ4XYitCovH1kc9OQdp_UaTgDbmfiUnS_0K5F6HlR04_qFuuGQ$> For prior releases of RAJA -- we were using built-in camp, but now that we are using a separate camp build for associated 2022.03 releases, this is a blocker for enabling RAJA+HIP in Ascent. I am happy to help fix and test this. — Reply to this email directly, view it on GitHub<https://urldefense.us/v3/__https://github.com/LLNL/camp/issues/113__;!!G2kpM7uM-TzIFchu!g2CjKFREf2lPazYosZ4XYitCovH1kc9OQdp_UaTgDbmfiUnS_0K5F6HlR05eQhGCMg$>, or unsubscribe<https://urldefense.us/v3/__https://github.com/notifications/unsubscribe-auth/AAFBFNJOGHYVVCMTMZU3D2DVXRYZRANCNFSM55UPWYJA__;!!G2kpM7uM-TzIFchu!g2CjKFREf2lPazYosZ4XYitCovH1kc9OQdp_UaTgDbmfiUnS_0K5F6HlR069iLH4jQ$>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[cyrush]

Thanks @trws I appreciate how complex this.

I am not a fan of the attempt at magic with BLT exported targets, it seems like a lot more work to keep healthy than just using CMake's standard targets and setting up things with find_package upon import.

We have stand alone using-with-cmake and using-with-make examples in our CI that catch lots of tricky issues that would otherwise be seen by users.

I'll keep an eye out on RAJA and Umpire PRs and test them.

[trws]

Thanks @trws I appreciate how complex this.

I am not a fan of the attempt at magic with BLT exported targets, it seems like a lot more work to keep healthy than just using CMake's standard targets and setting up things with find_package upon import.

I completely agree FWIW, but the coordination was already such a problem I decided to defer the fix I'd rather make in BLT itself until after we got spack packages and non-BLT downstreams at least unbroken. Part of the trick that makes this extra nasty is that the BLT targets don't actually work correctly in some cases when consumed by non-BLT projects, because they can't control the language property for dependents, or adjust things like the appropriate openmp flag if the dependent uses a different compiler. Kokkos deals with this by leaving everything as c++ and redirecting the compiler in a wrapper to the appropriate language compiler, which works but I'm not really sure is better. In the end I think what I really want us to get to is a BLT or BLT-targets or something that we can install, that provides all of this in a way that works the way we want without each package having to rebuild it explicitly, so we can just find_package(blt) and have it set the stuff up. That's a bigger job though unfortunately and might be a breaking change. Would love your thoughts on this, especially if you can think of something simpler.

We have stand alone using-with-cmake and using-with-make examples in our CI that catch lots of tricky issues that would otherwise be seen by users.

David added a using-with-cmake for raja that's been invaluable in all of this, the using-with-make idea is a good one too, should make sure we cover the pkgconfig output right with that.

I'll keep an eye out on RAJA and Umpire PRs and test them.

Thanks a lot!