On Tue, 3 Sept 2024, 10:15 Iain Sandoe, <i...@sandoe.co.uk> wrote: > Hi Folks, > > When we build a C++ binary module (CMI/BMI), we obviously have access to > its source to produce diagnostics, all fine. > > However, when we consume that module we might also need access to the > sources used to build it - since diagnostics triggered in the consumer can > refer back to the sources used. >
I'm fairly convinced by your argument that building the module usually happens as part of the same build as consuming the module, and so the sources will be available anyway. For large scale build environments where pre-built BMIs might be deployed by one team and consumed by other teams, without (re)building those BMIs, it doesn't seem too difficult for the module interface sources to also be deployed. That's not so different from deploying headers and libraries (.so, .dlsym, .dll etc) today. So I don't actually see a need to embed sources. It seems like it's solving something that can easily be solved using existing processes. Just include sources with BMIs that you deploy. If the full sources are sensitive IP, separate your code into the public parts that are used to compile the BMI and the non-public parts. Or proprietary vendors who don't want to do that separation can choose to not provide code, and diagnostics suffer for their users. That's not a technical problem, and doesn't need to be solved by the compiler. > Currently clang has been experimenting with embedding the sources into the > BMI - this can make things seem more efficient when, for example, > distributing BMIs to remote nodes in a large-scale distributed build. > > There was a patch proposed to make this the default for clang, which has > resulted in the discussion here: > > > https://discourse.llvm.org/t/rfc-modules-should-we-embed-sources-to-the-bmi/81029 > > Does GCC have a plan to deal with this? > .. if so can we communicate it.. > .. if not, then what do we think about this strategy? > .. at the very least trying to avoid tooling divergence seems a worthwhile > objective. > >
