Barry Smith <bsm...@mcs.anl.gov> writes: >> 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.
Note that petscdmda.h is not included by petscdm.h. I lean toward slimmer includes, but also see no value in breaking a build by removing any automatic include that most people need. We could consider removing petscao.h from petscdmda.h, for example, but I wouldn't want to add it to petscvec.h. I think petscis.h is sufficiently widely used that removing it doesn't make sense, though if we were starting afresh, we might make it separate.
signature.asc
Description: PGP signature