Dear Mikael, Thanks for your comments. I will commit the patch tonight. If folk get steamed up about .smod files appearing when they compile their favourite non-submodule-based code, I guess that we can put in a compilation flag to suppress them. We have plenty of time to tweak this before the release of 6 branch.
Once committed, I will get on with the documentation and updating of gfortran wiki. Cheers Paul On 3 August 2015 at 17:39, Mikael Morin <mikael.mo...@sfr.fr> wrote: > Le 03/08/2015 14:36, Paul Richard Thomas a écrit : >> >> Dear Mikael, >> >> Thanks for your green light! >> >> I have been mulling over the trans-decl part of the patch and having >> been wondering if it is necessary. > > You mean marking entities as public? Or setting the hidden visibility > attribute? Or both? > I think both are necessary. > >> Without optimization, private >> entities can be linked to. Given the discussion concerning the >> combination of submodules and private entities, I wonder if this is >> not sufficient? Within submodule scope, an advisory could be given for >> undefined references to suggest recompiling the module without >> optimization or making the entities public. >> > About recompiling without optimization: > If the module contains no code, I guess that would be OK. > But otherwise, it would be pretty bad. > And one would have to do the same for submodules of a submodule: the parent > submodule would be compiled without optimization. :-( > > About making the entities public: > I think the goal of submodules is providing a way to specify a (hopefully) > stable interface free of any internal implementation details that users > would start playing with if the opportunity was given to them. Making all > entities public would go against that. > > > I've been reading about the hidden visibility attribute since you submitted > the 3/3 patch(es). I think it's the right thing. :-) > > Mikael -- Outside of a dog, a book is a man's best friend. Inside of a dog it's too dark to read. Groucho Marx