On Tue, 3 Sept 2024 at 12:30, Jonathan Wakely <jwakely....@gmail.com> wrote: > > > > 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.
Reading this back, I realise "include" is ambiguous :-) I don't mean embed within the BMI, I mean deploy alongside. > 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. >> >>
