Matthew Knepley <knep...@gmail.com> writes: > On Sat, Jun 29, 2019 at 8:39 AM Jed Brown <j...@jedbrown.org> wrote: > >> Matthew Knepley <knep...@gmail.com> writes: >> >> > On Fri, Jun 28, 2019 at 4:37 PM Jed Brown <j...@jedbrown.org> wrote: >> > >> >> Matthew Knepley <knep...@gmail.com> writes: >> >> >> >> > On Fri, Jun 28, 2019 at 2:04 PM Smith, Barry F. via petsc-dev < >> >> > petsc-dev@mcs.anl.gov> wrote: >> >> > >> >> >> >> >> >> You are right, these do not belong in petscconf.h >> >> >> >> >> > >> >> > The problematic thing here is hiding information from users of >> >> > PETSc. If you are a user that counts on PETSc configure to check >> >> > something, but then we hide it because we do not use it, I would not >> >> > be happy. >> >> >> >> You want PETSc to test things that it doesn't use because maybe a user >> >> would want to know? Where does that end >> > >> > >> > Very clearly it ends with testing the things users SPECIFICALLY ASKED >> > US TO TEST on the configure command line. >> >> They asked us to test the size of short and for the existence of sched.h >> and mkstemp? >> > > I have no problem trimming the automatic tests we do (I copied them from > Autoconf), > as long as we provide a way to turn them on again.
I want to delete the code that we don't use. In the rest of PETSc, when we delete code, we delete it, not comment it out or make it optional and untested. >> >> and how would we ever know if >> >> the information is correct? >> >> >> > >> > This is just nonsensical. We know its correct because we tested it. >> >> Only by the code that decides whether to define the macro, but if one of >> those tests is/becomes broken (this has happened), we wouldn't know. >> > > I am not sure that worrying that code might become broken is a first order > problem. This unused & untested code is a net liability, not an asset.
