| -----Original Message-----
| From: Modules <modules-bounces_at_[hidden]> On Behalf Of Matthew
| Woehlke
| Sent: Tuesday, June 18, 2019 9:14 AM
| To: Corentin <corentin.jabot_at_[hidden]>; modules_at_[hidden]
| Cc: sg15_at_[hidden]; Olga Arkhipova <olgaark_at_[hidden]>
| Subject: Re: [isocpp-modules] [SG15] Reuse of the built modules (BMI) paper
|
| On 18/06/2019 02.52, Corentin wrote:
| > Is there anything as "slightly different compilation options" ? Given that
| > almost everything can be observed from the source code, a compiler
| should
| > be conservative with what it considers "reusable".
| > Let's not sacrifice correctness and reliability for the sake of compilation
| > times (even if that appears to be often the case regardless of modules)
|
| Just because something is *observable* doesn't mean that it *is*
| observed (or that it produces a change in the BMI even if it is). I
| would guess that >90% of the time there are very few compile options
| that actually affect the BMI.
|
| In fact, I would question if e.g. debugging information and optimization
| levels affect the BMI. They affect the *object code*, sure enough, but
| it seems like they *shouldn't* affect the BMI...

You are right spot on for the case of MSVC. I wouldn't be surprised if that was the case of Clang too. I am less familiar with how GCC does things these days.

| Likewise, there are nearly infinite numbers of PP symbols I can define
| which have no effect on the BMI because they don't appear in the source
| file.
|
| It doesn't seem implausible that compilers should be able to record
| every PP symbol that was evaluated and its value, and ignore any symbols
| outside that set for the purposes of determining if a BMI is "compatible".

That is exactly what we are planning on doing for macros defined on the command line (configuration parameters) in MSVC.

-- Gaby