Gabriel Dos Reis <gdr@microsoft.com> writes:
> There are environments where the static inputs to the builds and
> a transcript of the decision making process need to be persisted
> for post-build auditing (was the build subverted in unsuspected
> ways?); that is fundamental and non-negotiable in those setups.
Sure, nothing prevents you from saving the transcripts of the module
mapper exchange. In fact, build2 does this at a sufficiently high
verbosity levels along with the command lines to allow the user to
replay the mapper replies, say, for troubleshooting.
> I do find values in a module mapper where an interactive
> development (like active IDE development) can do with dynamic
> queries. But I am skeptical that it is the answer for all.
Sure, module mapper approach is not without its complications (I
even wrote a paper on this). But so far the only proposed alternative
is to pre-scan the world, which doesn't feel scalable (and, as you
know, I have doubts it can be implemented correctly for header units).
We have already deployed this for Clang modules. I don't see anything about header units that would make our approach invalid. It's also quite scalable, and we start dispatching module builds while scanning non-importable units.
- Michael Spencer
_______________________________________________
Ext mailing list
Ext@lists.isocpp.org
Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
Link to this post: http://lists.isocpp.org/ext/2022/04/19015.php