Date: Wed, 7 Jul 2021 20:31:59 -0400
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
> 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
Received on 2021-07-07 19:32:04