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

Improve BLT's export logic #593

Open
white238 opened this issue Aug 11, 2022 · 1 comment
Open

Improve BLT's export logic #593

white238 opened this issue Aug 11, 2022 · 1 comment

Comments

@white238
Copy link
Member

We should help with exporting CMake targets better. The following two ideas were proposed:

  1. Add export options to blt_add_library, for example, export namespace and export set name. This could probably be just one optional parameter: blt_add_library(NAME foo ... EXPORT myProjectName)
  2. Improve blt_export_tpl_targets() in two ways: first, add the ability to export project specific TPLs under your projects namespace, and second, have blt export its targets to a blt specific namespace and have the exported targets be granular so that you can add targets as you build up your connected projects (think, camp exporting from raja, then umpire adding mpi because neither needed them)
@cyrush
Copy link
Member

cyrush commented Aug 11, 2022

Maybe I am missing something, but does the first one add much? There are other paths associated with how the exports are installed, will we have to pass those to our macro as well?

If folks want to rely on bona-fide BLT targets (as opposed to say using standard CMake targets like for MPI) -- should there be a path for find_package(blt_targets)?

The problem I see with both that and even with the magic exports, is the BLT targets are baked in for each project. Even if they are renamed, there could be problems, the could be incompatible.

This is the OpenMP issue. If I have one package that didn't use OpenMP and one later wants to use it, BLT's baked in stuff can get very confused b/c of language support.

When you do things like find_package(OpenMP) downstream -- CMake handles the transitive cases much better.

I really think we should consider if the export magic is taking us further down the rabbit hole, or if we should move towards something else.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants