[petsc-dev] Unused macros in petscconf.h

Jed Brown jed at jedbrown.org
Sat Jun 29 10:04:55 CDT 2019


Matthew Knepley <knepley at gmail.com> writes:

> On Sat, Jun 29, 2019 at 8:39 AM Jed Brown <jed at jedbrown.org> wrote:
>
>> Matthew Knepley <knepley at gmail.com> writes:
>>
>> > On Fri, Jun 28, 2019 at 4:37 PM Jed Brown <jed at jedbrown.org> wrote:
>> >
>> >> Matthew Knepley <knepley at gmail.com> writes:
>> >>
>> >> > On Fri, Jun 28, 2019 at 2:04 PM Smith, Barry F. via petsc-dev <
>> >> > petsc-dev at 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.


More information about the petsc-dev mailing list