On Mon, Jun 21, 2021, at 09:25, Poliakoff, David Zoeller via SG15 wrote:
> 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?

you *might* want to pick a better language than golang 😅. The approach there is to use special "pragma comments" that work with gcc (and only gcc!). There is nothing you can really do to get around this, though I discovered you can use //go:generate to generate another file that has the correct //go:build pragma comments. But then your build goes from go build ./... to go generate ./...; go build ./... and this is apparently *too much* for a lot of people. Golang is extremely hostile to FFI and this is by design.

In the case of rust, rustc itself does not know how to link this code into a crate, but rustc is dependent on the same linker as C++ and in some cases just calls the C or C++ compiler directly (and in the case of the stable-x86_64-pc-windows-gnu toolchain, they just provide a moderately out of date implementation of gcc). Tools like cargo handle some of this for you, but the real 'magic' for rust is that one crate is one translation unit and this simplfies a lot of the linking. But in the end you're actually usually taking the MSVC route and (instead of using a pragma) using a #[link(...)] attribute at the file scope, though it can also be attached to modules IIRC.

> 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_[hidden] <mailto:sg15-bounces%40lists.isocpp.org> on behalf of sg15_at_[hidden] <mailto:sg15%40lists.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] <mailto:SG15%40lists.isocpp.org>
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden] <mailto:SG15%40lists.isocpp.org>
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>