This would be beautiful, but one worry I have is that CMake handles a lot of ugly "if a target does X in Fortran, and a target Y in C++ depends on it, you need to add -foo to the CXXFlags." It's pretty gross. Add in the CUDA as a "language" support and you multiply the grossness. That said, I'm 100% with you on this being desirable, one of the ugly parts of CMake is how it integrates with a build system that uses pkg-config, or does something gross with their CMake, if those CMake scripts could become five lines on top of "just read the CPS artifact and do what is says, forehead" I would not be opposed.

Does anybody know how/if these newer languages handle linking in external source code? Like, if I have Golang (picking randomly) app that needs visibility into a C++ and HIP library's headers, what that looks like? Or perhaps the Golang flags need to change based on how that library was compiled?

Also I'm reading this, people feel free to say "that's for the Packaging WG" and I'll leave it off of this thread

Best,

David P

On 6/21/21, 9:29 AM, "SG15 on behalf of Matthew Woehlke via SG15" <sg15-bounces_at_lists.isocpp.org on behalf of sg15_at_lists.isocpp.org> wrote:

... (Admittedly, I don't have the time to dig into it too
    much, and am not as involved with build systems now as I was a few years
    ago. What I want to see, however, is a concerted effort being made to
    replace CMake's native package scripts.)

   ...

    --
    Matthew
    _______________________________________________
    SG15 mailing list
    SG15_at_[hidden]
    https://lists.isocpp.org/mailman/listinfo.cgi/sg15