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.

Attachment: signature.asc
Description: PGP signature

Reply via email to