<div dir="ltr"><div>On Tue, 12 Feb 2019 at 23:38 Steve Downey <<a href="mailto:sdowney@gmail.com">sdowney@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Separately from general packaging, I do want to see a solution to getting bmi from a nightly build, just so I don't have to teach my build to build every transitive BMI, I can just use them. This would be in a tightly controlled environment, same compiler, mostly same flags, etc. Even if the time is de minimus for one, there are a lot of them. Assuming that we have one module per component, which is our desired state. </div></blockquote><div><br></div><div><span style="font-size:13px">If you have a controlled environment there should be no issue.</span><br></div><div><br></div><div>I think the following could help with caching bmi safely</div><div><br></div><div><br></div><div> * A mechanism by which given a set of compilation flags, a compiler would</div><div>generate a string that would be identic for all set of compilations that might not</div><div>result in a different output</div><div><br></div><div>g++ -id foo.cpp</div><div>abc</div><div>g++ -id foo.cpp -Wall<br></div><div>abc</div><div>g++ -id foo.cpp -O3<br></div><div>dfe</div><div><br></div><div>This would let you cache the BMI</div><div><br></div><div> * A mechanism to generate a string from a Module Interface Unit or a BMI such that the same string would be generated for 2 BMI if they have the same ABI</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 12, 2019 at 5:33 PM Steve Downey <<a href="mailto:sdowney@gmail.com" target="_blank">sdowney@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Right now, they ship headers. They can't ship BMI's because BMI's are<br>
not portable across compilers or quite possibly even compiler versions.<br>
Shipping raw source will not be an option for non-open-source libraries.<br>
<br>
We need an intermediate representation that is *portable*.<br><br></blockquote></div></div><div dir="ltr"><div class="gmail_quote"><div>Source for the module interface. If you don't want to provide details in the module interface, then don't. You are no worse off than if you provided headers. </div><div><br>export module my_closed_source;<br></div><div>export import "my_closed_source_header.h"<br><br>We do need some ground rules for how to consume the source of an interface unit. I believe the compiled interface should be in a library, or otherwise provided, and the consumer just translate the interface into the bmi, because providing a .o and a .a to a posix linker has very different effects. The object file is added unconditionally, and its undefs must be resolved, where a library is just a source for undef resolution. <br><br><br></div><div><br></div><div> </div></div></div>
</blockquote></div>
_______________________________________________<br>
Tooling mailing list<br>
<a href="mailto:Tooling@isocpp.open-std.org" target="_blank">Tooling@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/tooling" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/tooling</a><br>
</blockquote></div></div>