blt icon indicating copy to clipboard operation
blt copied to clipboard

Improve BLT's export logic

Open white238 opened this issue 1 year ago • 1 comments

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)

white238 avatar Aug 11 '22 21:08 white238

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.

cyrush avatar Aug 11 '22 22:08 cyrush