<div dir="ltr"><div dir="ltr">On Sat, Jun 29, 2019 at 8:39 AM Jed Brown <<a href="mailto:jed@jedbrown.org">jed@jedbrown.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> writes:<br>
<br>
> On Fri, Jun 28, 2019 at 4:37 PM Jed Brown <<a href="mailto:jed@jedbrown.org" target="_blank">jed@jedbrown.org</a>> wrote:<br>
><br>
>> Matthew Knepley <<a href="mailto:knepley@gmail.com" target="_blank">knepley@gmail.com</a>> writes:<br>
>><br>
>> > On Fri, Jun 28, 2019 at 2:04 PM Smith, Barry F. via petsc-dev <<br>
>> > <a href="mailto:petsc-dev@mcs.anl.gov" target="_blank">petsc-dev@mcs.anl.gov</a>> wrote:<br>
>> ><br>
>> >><br>
>> >>   You are right, these do not belong in petscconf.h<br>
>> >><br>
>> ><br>
>> > The problematic thing here is hiding information from users of<br>
>> > PETSc. If you are a user that counts on PETSc configure to check<br>
>> > something, but then we hide it because we do not use it, I would not<br>
>> > be happy.<br>
>><br>
>> You want PETSc to test things that it doesn't use because maybe a user<br>
>> would want to know?  Where does that end<br>
><br>
><br>
> Very clearly it ends with testing the things users SPECIFICALLY ASKED<br>
> US TO TEST on the configure command line.<br>
<br>
They asked us to test the size of short and for the existence of sched.h<br>
and mkstemp?<br></blockquote><div><br></div><div>I have no problem trimming the automatic tests we do (I copied them from Autoconf),</div><div>as long as we provide a way to turn them on again.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>> and how would we ever know if<br>
>> the information is correct?<br>
>><br>
><br>
> This is just nonsensical. We know its correct because we tested it.<br>
<br>
Only by the code that decides whether to define the macro, but if one of<br>
those tests is/becomes broken (this has happened), we wouldn't know.<br>
</blockquote></div><br clear="all"><div>I am not sure that worrying that code might become broken is a first order problem.</div><div><br></div><div>   Matt</div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead.<br>-- Norbert Wiener</div><div><br></div><div><a href="http://www.cse.buffalo.edu/~knepley/" target="_blank">https://www.cse.buffalo.edu/~knepley/</a><br></div></div></div></div></div></div></div></div>