<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 18, 2013 at 8:11 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I hit upon docs/SystemLibrary.rst today.<div><br></div><div>Is this documentation useful to anyone?  Can I delete it?</div>
<div><br></div><div>Most of the guidelines seem like common sense: Keeping LLVM Portable, High Level Interface, No Unused Functionality, No Duplicate Implementations, etc.</div></div></blockquote><div><br></div><div>They aren't all written down elsewhere, so I oppose removing them. Also, as a general rule, I look with extreme scrutiny at anything that would break the validity of existing URL's.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<div><br></div><div>Some are not really true, like "Minimize Soft Errors".  We currently propagate a lot of file-related soft errors up as llvm::error_codes.</div></div></blockquote><div><br></div><div>Please fix that one to describe the current best-practices for error handling.</div>
<div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Only a few seem useful to me: Don’t Expose System Headers (basically, no windows.h) and No Virtual Methods.</div>

</div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Tue, May 28, 2013 at 7:06 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>

</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div>>> Ideally we would have a<br>
>> docs/SystemLibrary.rst that would just says "this library has been<br>
>> merged to lib/Support" and docs/SupportLibrary.rst documents whatever<br>
>> is in lib/Support.<br>
><br>
><br>
> Considering our OS portability layer to be it's own separate thing, even if<br>
> it isn't its own lib/* directory is probably a good distinction to make<br>
> regardless. And SystemLibrary.rst is well-written and has excellent, focused<br>
> content about LLVM's approach to OS portability.<br>
><br>
> After thinking about this a bit more, it's not clear to me that it would be<br>
> beneficial to include this content into a general page about libSupport, as<br>
> that would make it less focused and harder to find. If anything, it would be<br>
> "ideal" to put it into a file Portability.rst (or similar), but that's a<br>
> marginal benefit anyway since it is already one of the top hits when<br>
> searching "llvm portability". We can really easily massage the title and<br>
> content (such as referenced file paths), like what happended to<br>
> clang/docs/Tooling.rst, which is now "Choosing the Right Interface for Your<br>
> Application" <<a href="http://clang.llvm.org/docs/Tooling.html" target="_blank">http://clang.llvm.org/docs/Tooling.html</a>>.<br>
<br>
</div>That is ok. It is the reference to libSystem that is confusing, so<br>
making this file about the "portability features in lib/Support" would<br>
be great!<br>
<br>
> -- Sean Silva<br>
</div></div><div><div><br>
Cheers,<br>
Rafael<div class="im"><br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div></div></div></blockquote></div><br></div>
</blockquote></div><br></div></div>