Subject: Re: [EXTERNAL] Re: Draft: Requirements for Usage of C++ Modules at Bloomberg
From: Poliakoff, David Zoeller (dzpolia_at_[hidden])
Date: 2021-06-21 11:25:47
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
ï»¿On 6/21/21, 9:29 AM, "SG15 on behalf of Matthew Woehlke via SG15" <sg15-bounces_at_[hidden] on behalf of sg15_at_[hidden]> 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.)
SG15 mailing list
SG15 list run by firstname.lastname@example.org