-
Notifications
You must be signed in to change notification settings - Fork 35
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
cmake-rdc: add support for MODULE library. #848
cmake-rdc: add support for MODULE library. #848
Conversation
And a few cleanups (See STREQUAL usage)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, I guess it was quite a simple change after all. You said that replacing this with the standalone https://github.com/pcanal/CudaRDCExercise will happen in a separate commit?
arg STREQUAL "EXCLUDE_FROM_ALL" OR | ||
arg STREQUAL "STATIC" OR | ||
arg STREQUAL "SHARED" OR | ||
arg STREQUAL "MODULE" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe simplify to arg MATCHES "^[A-Z_]+$"
? All source files will have an extension.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I could do that .. note that this code is literally inspired by Kitware's code in FindCUDA.mk: Kitware/CMake@b8b53db/Modules/FindCUDA.cmake#L1327
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The FindCUDA is very old but you have a point... I'm just concerned about more library arguments being added by kitware.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All looks good to me! Have tested on the FullSimLight module library that exposed the problem and confirmed the changes here resolve the issue, so good to go on that side of things.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I noticed a couple of places that could use fixing/improving
A separate PR as it is semantically unrelated. |
So is the replacement of "x" which made this harder to review 😬 |
PR celeritas-project#848 taught celeritas_target_link_libraries that MODULE targets are always the final one in any link chain and hence to device link them correctly. Update text on MODULE vs SHARED targets to account for this update. Retain text on explicit linking of final target to cover case of projects that enforce use of SHARED targets for plugins.
* Document how to link loadable shared libraries with Celeritas Integration of Celeritas in ATLAS's FullSimLight required it to be used in and linked from a shared library loaded by the FullSimLight application at runtime (a "plugin"). `celeritas_target_link_libraries` on the plugin library did not result in the needed "_final" device code library being linked to it, leading to undefined symbols at load time. Traced to `celeritas_target_link_libraries` not considering a shared library as an endpoint required full device link resolution. Briefly describe this use case in documentation and provide example of how to link a "plugin" shared library to Celeritas targets. * Clarify shared/module library linking after RDC update PR #848 * Clarify shared/module library linking after RDC update PR #848 taught celeritas_target_link_libraries that MODULE targets are always the final one in any link chain and hence to device link them correctly. Update text on MODULE vs SHARED targets to account for this update. Retain text on explicit linking of final target to cover case of projects that enforce use of SHARED targets for plugins. * Address review comments on Celeritas CMake wrappers Show use of Celeritas wrappers in all places, noting decay properties allowing any combination of CUDA/CPU compiling and linking. * Clarify use cases for linking to SHARED plugin library Celeritas recommends use of celeritas_add_library to support the full RDC chain but it may not be possible to use this in projects that provide their own wrappers over the raw CMake commands. Add clarification on the use case here, retaining example use of raw CMake commands for simplest possible use case.
And a few cleanups (See STREQUAL usage)