Dear Damian, I do not think that there is any effect on compilation cascades. As long as the private part of the module file remains unchanged, it will not be recompiled if a descendant submodule is modified. Naturally, the size of the module file is increased but, if one is careful, this is not a big deal. A gotcha, which I will have to emphasize in the documentation occurs if another module file is used and its symbols are not exposed by public statements. If there are large numbers of symbols this can have a big effect on the size of the module file. I noticed this, when examining one of gfortran's testcases where the ISO_C_BINDING intrinsic module is used. Generous sprinklings of USE ONLYs are required to keep the module file sizes under control.
I am not over enthusiastic about using compilation flags to uphold standards either. Cheers Paul On 23 July 2015 at 10:22, Damian Rouson <dam...@sourceryinstitute.org> wrote: > > >> On Jul 23, 2015, at 12:46 AM, Paul Richard Thomas >> <paul.richard.tho...@gmail.com> wrote: >> >> Since all the private entities in a module have to be transmitted to >> their descendant submodules, whilst keeping them hidden from normal >> use statements, I have chosen to write the module file as usual and >> add a second part that contains the private entities. This latter is >> only read when processing submodule statements. > > Hi Paul, > > Could you comment on whether this approach alleviates compilation cascades as > seems to have been envisioned when submodules were added to the standard? My > guess is that a developer could adopt a policy of putting only public > information in a > module and reserving all private information for submodules, which would > mitigate > against unnecessary compilation cascades and would be consistent with putting > the interface in the module and the implementation in a submodule.. > >> It does cross my mind that all of this part of the submodule >> implementation could be subject to the condition that a compiler >> option is set. I am struck by the notion that making private module >> entities available to submodules is an unnecessary complication and >> that it amounts to be an error in the standard. This is why I am >> suggesting the possibility of a specific compiler option. > > I strongly advocate against having to pass flags to force standard-compliant > behavior > (I happened to have just posted to c.l.f on a frustrating way in which two > compilers > currently require flags to comply with the standard), although it sounds like > it might > not matter in this case if one adopts the aforementioned policy > of putting only pubic information in modules. > > Damian -- Outside of a dog, a book is a man's best friend. Inside of a dog it's too dark to read. Groucho Marx
