<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 7, 2021 at 12:45 PM Reid Kleckner <<a href="mailto:rnk@google.com">rnk@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Fri, Jul 2, 2021 at 5:22 PM Mehdi AMINI via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>I think part of the confusion on my side in this thread is that when I read "binary utilities" I thought first and foremost about `opt` and `lld`, while you're using "binary utilities" to refer to what I would call "end-user tools".<br>I agree with you that tools like clang and lld are in a different category than `opt`.</div><div><br></div><div>cl::opt as it may not be suitable as-is, but OptTable being not composable and not offering any facility to someone building a tool to re-expose library options is also quite limited. It seems to me that we need such a solution, and it also seems that if we had such solutions it would be suitable for all the tools we intend to build using LLVM-based libraries.</div><div>Without any plan to build this though, I'm not trying to block progress on your cleanup/improvement of these end-user tools :)</div><div></div></div></div></blockquote><div> </div><div>I wanted to express my agreement:<br><ul><li>OptTable is reasonable when attempting to implement a closed, compatible command line interface</li><li>We should not view cl::opt's library registration design as somehow "evil": There is much room for improvement</li></ul><div>So, yeah, for all our GNU-compatible tools, go ahead and use the Option library.</div></div><div><br></div><div>I think cl::opt has a future in LLVM, but that's worth it's own discussion thread. The MLIR conventions help a lot, but they still appear to use a global command line registry, which isn't ideal for some use cases.</div></div></div></blockquote><div><br></div><div>Indeed, getting rid of the global state would be ideal, but that also seems much more challenging from an API design point of view: do you have ideas on this?</div><div><br></div><div>In the meantime, to improve the situation with libSupport, I just wrote  <a href="https://reviews.llvm.org/D105959">https://reviews.llvm.org/D105959</a> </div><div>(we're reusing libSupport in various situation and get hit by the eager registration of cl::opt and other globals in some cases)<br></div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div><div><br></div><div><br></div><div> </div></div></div>