<div dir="ltr">On 1 June 2013 21:07, Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><span style="color:rgb(34,34,34)">The default build options are optimized for us developers (if</span><br>
</div>
anything) rather than anyone's actual use of LLVM.</blockquote><div><br></div><div style>Yes, and this is why...</div><div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Realistically, I don't see our binaries being used for much except<br>
experimentation.</blockquote><div><br></div><div style>Furthermore, while this is true...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> which we should make as easy as possible.</blockquote>
<div><br></div><div style>Enabling RTTI and Exceptions by default have the undesired side-effect that core development will, sometimes unintentionally, start using it and we'll create a necessity, when previously we had the option. </div>
<div style><br></div><div style>Leaving those options disabled by default have little to do with ease of use, but with design decisions that I don't think should change, just for the sake of usability.</div><div style>
<br></div><div style>Usability can be controlled at a package level (or build level), and that's the job of the distribution packaging process, or the expert developers, not the tool itself.</div><div style><br></div>
<div style>The options are there, and even documented to make the advanced building/packaging easier, but making that a default is teaching the wrong lesson.</div><div style><br></div><div style>Our binaries are not used that much to warrant being user-friendly. Production environments should use pre-packaged binaries, specialized packages or hand-crafted tar-ballz, and not the "default" binaries. </div>
<div style><br></div><div style>If anything, those binaries are a reference, to which you'll compare your specialized build to see what gain you had, or what functionality you're missing. End users should do none of that, and rely on DEB and RPM packages, and complain to their distribution managers to pack this or that feature next time.</div>
<div style><br></div><div style>cheers,</div><div style>--renato</div></div></div></div>