<div dir="ltr">We could also start putting a "tested against …" statement in the release notes for posterity.<div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature">David E DeMarle<br>Kitware, Inc.<br>R&D Engineer<br>21 Corporate Drive<br>Clifton Park, NY 12065-8662<br>Phone: 518-881-4909</div></div>
<br><div class="gmail_quote">On Wed, Jun 10, 2015 at 10:51 AM, David E DeMarle <span dir="ltr"><<a href="mailto:dave.demarle@kitware.com" target="_blank">dave.demarle@kitware.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">That took longer than expected Bill. :) <div><br></div><div>Thanks for bringing up the counter argument Bill. Casey's pain demonstrates your point.<div><br></div><div>Despite that my vote is for getting rid of old compilers sooner rather than later. Old compilers are a drag on both innovation and maintenance.</div><div><br></div><div>Whatever we do I think the we need to clearly communicate what compilers we really are trying to support. This discussion and earlier ones on the mailing list help. The cmake macros people have discussed will help too. In practice the dashboards submitters define the set of compilers that people can expect to "just work". That set should be introspected and published automatically and expanded.</div><div><br></div></div></div>
</blockquote></div><br></div>