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

cmake-rdc: add support for MODULE library. #848

Merged
merged 2 commits into from
Jul 12, 2023

Conversation

pcanal
Copy link
Contributor

@pcanal pcanal commented Jul 10, 2023

And a few cleanups (See STREQUAL usage)

And a few cleanups (See STREQUAL usage)
@pcanal pcanal requested review from sethrj and drbenmorgan July 10, 2023 18:41
@pcanal pcanal self-assigned this Jul 10, 2023
Copy link
Member

@sethrj sethrj left a 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?

cmake/CeleritasLibrary.cmake Outdated Show resolved Hide resolved
cmake/CeleritasLibrary.cmake Outdated Show resolved Hide resolved
arg STREQUAL "EXCLUDE_FROM_ALL" OR
arg STREQUAL "STATIC" OR
arg STREQUAL "SHARED" OR
arg STREQUAL "MODULE"
Copy link
Member

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.

Copy link
Contributor Author

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

Copy link
Member

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.

Copy link
Contributor

@drbenmorgan drbenmorgan left a 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.

cmake/CeleritasLibrary.cmake Outdated Show resolved Hide resolved
Copy link
Member

@sethrj sethrj left a 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

@pcanal
Copy link
Contributor Author

pcanal commented Jul 12, 2023

You said that replacing this with the standalone pcanal/CudaRDCExercise will happen in a separate commit?

A separate PR as it is semantically unrelated.

@sethrj
Copy link
Member

sethrj commented Jul 12, 2023

So is the replacement of "x" which made this harder to review 😬

@sethrj sethrj merged commit cdeb6e2 into celeritas-project:develop Jul 12, 2023
drbenmorgan added a commit to drbenmorgan/celeritas that referenced this pull request Jul 19, 2023
drbenmorgan added a commit to drbenmorgan/celeritas that referenced this pull request Jul 19, 2023
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.
sethrj pushed a commit that referenced this pull request Jul 26, 2023
* 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.
@sethrj sethrj added core Software engineering infrastructure minor Minor internal changes or fixes labels Aug 2, 2023
@pcanal pcanal deleted the SupportModuleLibrary branch October 18, 2024 08:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Software engineering infrastructure minor Minor internal changes or fixes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants