<div dir="ltr">No disagreement there. We illustrate with scenarios we have only because we can speak confidently about them, and the hope was they may resonate with others' (we didn't expected them to be sufficient motivation, had they been ours alone). If it turned out that no one had similar scenarios, or the design was too narrow, we would have sought an outside-llvm alternative, for all the reasons you mention. In this case, RemarksEmitter seems to suggest related problems were addressed already.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 6, 2020 at 9:17 AM Renato Golin <<a href="mailto:rengolin@gmail.com">rengolin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 6 Aug 2020 at 16:49, Mircea Trofin <<a href="mailto:mtrofin@google.com" target="_blank">mtrofin@google.com</a>> wrote:<br>
> At a high level, you are right, the 2 alternatives are similar, but the devil is in the details. The build system (basel-based) is hermetic, and needs to be aware of all such extra files, and have a separate rule to copy and concatenate them. This solution turned out to be much cleaner.<br>
<br>
Cleaner to your build system is not necessarily cleaner to LLVM and<br>
all its users (downstream and upstream) and sub-projects.<br>
<br>
What I'm trying to avoid is a custom-built solution injecting random<br>
sections in the ELF binary to fix a problem that a specific build<br>
system has for a specific project. That doesn't scale.<br>
<br>
Like Hal, I'm trying to get you to use existing solutions in LLVM to<br>
suit your needs, as the cost of keeping dangling features (ones used<br>
by a single project) in a code as large as LLVM usually doesn't pay<br>
off.<br>
<br>
Even if that makes your build system slightly worse, the benefit of<br>
not adding bespoke features, to all LLVM users (including you), is<br>
still very much positive.<br>
<br>
--renato<br>
</blockquote></div>