Hey Ben,

Thanks for looking at this, the main product I was hoping for was "the CMake folks are looking at this, and haven't quit software engineering to open up a taco truck." Your reply satisfies that.

Looking a bit more deeply, I think the system you're describing sounds fine, and like something we could train our users on. If you'd like, feel free to ping me if you ever have a prototype you want a friendly user to try out. We hit a lot of pathological cases in Kokkos, could be interesting to see how it all works out.

In any case, thanks very much for the reply.

Best,

David P

On 7/7/21, 6:32 PM, "Ben Boeckel" <ben.boeckel_at_kitware.com> wrote:

    On Mon, Jun 21, 2021 at 13:00:26 +0000, Poliakoff, David Zoeller via SG15 wrote:
> 2. Dependency info, how do I say I rely on a given library or set
> of source artifacts (previously I would have said “header files”).
> This is where I think a lot of the work comes in. I think the
> question here is whether a) targets (in a CMake sense) can be
> specified in terms of modules (“I depend on the Kokkos Core module
> and the Kokkos containers module”) and b) whether CMake can parse
> whatever module files we output in order to support this. Do we have
> a CMake guru in the group who can tell me “David, don’t worry, we’ve
> been planning for this?” My guess is that all of this is fine, but
> my guess is worth a lot less than somebody at Kitware saying “we’re
> not freaking out about this.”

    It's basically going to be new usage requirements. Just a short bullet
    list:

      - Targets will need to say "I provide module interface units X, Y, Z
        and importable header units at paths H, J, K" (there will likely be
        support commands to say "find all headers and attach them to target
        T).
      - There will need to be `MODULE` usage requirements because a module
        interface unit might privately `#include <zlib.h>`, but one doesn't
        want to leak that include path to `import
        privately.zlib.using.mod;`. This also means a `$<MODULE_ONLY:>`
        genex will have to exist at some point.
      - CMake will need to track installation of module interface units on
        installed targets. I'm not yet sure how to specify "this module is
        private, this one is public, and this other one is private, but
        needed by a public one" yet.

    Basically, manual `FindFoo` implementations with importable header units
    or modules is going to get a lot more complicated, though support APIs
    for projects following some patterns could be made pretty easily.

    Given this information, CMake should be able to make the commands to
    scan these module interface units as needed, build BMIs as needed, and
    continue on with the build. I'm expecting any prebuilt BMIs to turn
    "please make me a BMI" into a glorified copy from a cache, but that's a
    toolchain thing. I don't want CMake (or any build system) in the
    business of figuring out if a cached BMI is suitable or not since the
    compiler is, by definition, the arbiter of that answer anyways.

    By the way, all of this is *representable* in `pkg-config`, but it's not
    going to be easy from the `pkgconf` command line because you'll have to
    query for module names, then loop over those names to get information
    about each. Maybe `pkgconf` could synthesize it from something like
    `cxx20_module_dir = ${prefix}/modules/lib`, but getting that into the
    `pkg-config` implementations is going to be a tough sell I imagine.

    And if you want, yes, we've been brainstorming this, but haven't had the
    cycles to sit down and do the work.

    --Ben