<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""></div><div><br class=""></div><div>Thanks for taking a look! Eric and David beat me to responding. Below are a few additional thoughts in a similar direction.</div><div><br class=""><blockquote type="cite" class=""><div class="">On 25 Oct 2019, at 14:48, David Blaikie <<a href="mailto:dblaikie@gmail.com" class="">dblaikie@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><br class=""></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Oct 25, 2019 at 2:43 PM Michael Kruse via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I like the idea and already discussed it with Kit Barton.<br class="">
<br class="">
Two concerns that I had:<br class="">
<br class="">
1. Keeping them in-tree requires them to be up-to-date, a potential<br class="">
additional maintenance burden. This might be what we want, but I get<br class="">
less enthusiastic when thinking about maintaining all tutorials ever<br class="">
given at any conference during the last xx years without having gone<br class="">
through a review process.<br class=""></blockquote><div class=""><br class=""></div><div class="">As with any code in the codebase, yeah, pre or post commit review seems good & if they end up bitrotting/becoming less relevant/diverge significantly from the tutorial content (written, video, whatever there is) I think it's fine to delete them. Same as we'd do with tests. (I think they're sort of like tests, really)</div></div></div></div></blockquote><div><br class=""></div><div>I think that would be great policy. </div><div><br class=""></div><div>IMO, the examples should go through reviews as well and for any changes that break the examples, I think it is reasonable to expect the author to fix them, similar to breaking other parts of LLVM.</div><div><br class=""></div><div>But it might be unreasonable to expect people to also update accompanying material (e.g. a write up), except for trivial API changes. As David suggested, if they diverge too much, we can remove them (or try to find someone who is interested in updating them).</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br class="">
2.Chris Bieneman seeks to simplify the cmake build system, including<br class="">
significantly reducing the number of configuration parameters and<br class="">
making "make all" really make everything, including examples. This<br class="">
would make the overall configure process slower even when not<br class="">
interested in the tutorials.<br class=""></blockquote></div></div></div></blockquote><br class=""></div><div>The suggested approach does not introduce any new options/variables, it just adds an additional definition, if the existing LLVM_BUILD_EXAMPLES=On. So this should not interfere with reducing the overall options. Whatever solution will be applied to all examples should also work for the IR pass examples.</div><div><br class=""></div><div>Cheers,</div><div>Florian</div><br class=""></body></html>