Date: Mon, 21 Jun 2021 17:30:43 +0000
* 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
Yes, that was the plan with attributes on module declarations and import-declarations. Not yet implemented in released MSVC.
-- Gaby
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Isabella Muerte via SG15
Sent: Monday, June 21, 2021 9:34 AM
To: SG15 <sg15_at_[hidden]>
Cc: Isabella Muerte <imuerte_at_[hidden]>
Subject: Re: [SG15] [EXTERNAL] Re: Draft: Requirements for Usage of C++ Modules at Bloomberg
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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=04%7C01%7Cgdr%40microsoft.com%7C262869adc4df4082b70608d934d2618f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637598900457518820%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PFGLfrLwHCZd19bW%2FE8Bs9zj5Ph3SB%2BBlCKgeB2W9Tc%3D&reserved=0>
_______________________________________________
SG15 mailing list
SG15_at_[hidden]p.org<mailto:SG15%40lists.isocpp.org>
https://lists.isocpp.org/mailman/listinfo.cgi/sg15<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=04%7C01%7Cgdr%40microsoft.com%7C262869adc4df4082b70608d934d2618f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637598900457518820%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PFGLfrLwHCZd19bW%2FE8Bs9zj5Ph3SB%2BBlCKgeB2W9Tc%3D&reserved=0>
Yes, that was the plan with attributes on module declarations and import-declarations. Not yet implemented in released MSVC.
-- Gaby
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Isabella Muerte via SG15
Sent: Monday, June 21, 2021 9:34 AM
To: SG15 <sg15_at_[hidden]>
Cc: Isabella Muerte <imuerte_at_[hidden]>
Subject: Re: [SG15] [EXTERNAL] Re: Draft: Requirements for Usage of C++ Modules at Bloomberg
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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=04%7C01%7Cgdr%40microsoft.com%7C262869adc4df4082b70608d934d2618f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637598900457518820%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PFGLfrLwHCZd19bW%2FE8Bs9zj5Ph3SB%2BBlCKgeB2W9Tc%3D&reserved=0>
_______________________________________________
SG15 mailing list
SG15_at_[hidden]p.org<mailto:SG15%40lists.isocpp.org>
https://lists.isocpp.org/mailman/listinfo.cgi/sg15<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=04%7C01%7Cgdr%40microsoft.com%7C262869adc4df4082b70608d934d2618f%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637598900457518820%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=PFGLfrLwHCZd19bW%2FE8Bs9zj5Ph3SB%2BBlCKgeB2W9Tc%3D&reserved=0>
Received on 2021-06-21 12:30:50