On Fri, 4 Aug 2017, Barry Smith wrote: > > > On Aug 4, 2017, at 4:40 AM, Lisandro Dalcin <dalc...@gmail.com> wrote: > > > > On 4 August 2017 at 01:38, Jed Brown <j...@jedbrown.org> wrote: > >> Lisandro Dalcin <dalc...@gmail.com> writes: > >> > >>> On 2 August 2017 at 17:49, Satish Balay <ba...@mcs.anl.gov> wrote: > >>>> > >>>> On Wed, 2 Aug 2017, Lisandro Dalcin wrote: > >>>> > >>>>> Is this intentional or just an oversight? > >>>> > >>>> Probably an oversight.. > >>>> > >>>>> Should it be fixed in maint? > >>>> > >>>> Sure - with the bug-fix branch off maint - with testing in next first.. > >>>> > >>> > >>> Not sure about the proper way to add the include. I would say it > >>> should go to petscvec.h, as SF is part of the Vec package and > >>> libpetscvec. Do you agree? > >> > >> petscao.h is not included by any other headers in the Vec package. I'm > >> not sure why petscsf.h would be different. Why not just include it in > >> petsc.h? > >> > > > > Well, maybe that's an oversight, too. Including petscvec.h should > > include all what is available in the Vec package. Otherwise, why is > > petscis.h included in petscvec.h (It seems petscistypes.h is all what > > should be required for petscvec.h) ? I'm fine with doing things one > > way or another, but we should have a rule and be consistent about it. > > Is there a rule? If not, what should be the rule? > > We use to have massive over inclusion; Jed pushed for minimal includes > (which introduced things like petscXXXtypes.h) this improved compile times a > good amount. So I think our rule is to balance not having excessive > inclusions with simplicity for users. For example AO is not used by many > people who use Vec so it is not included in petscvec.h but IS is used by most > Vec users and hence is included by default. Similarly most people do not use > SF so it is not included by default. Note: how we determine if something is > used "by most users" is not defined.
Well I think: 1. petsc.h should include all modules within petsc. 2. individual modules like petscksp.h, petscts.h should only include their dependencies - and nothing else. [i.e Vec functions take IS as argument - so petscis.h should be included etc..] 3. Even if petscksp.h includes its dependency is.h - its best to list it also in petsc.h [they are protected from multiple inclusion anyway] - but petsc.h should give a summary of all modules provided by petsc - in a reasonable dependency order. Satish
