From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105513 invoked by alias); 23 Jul 2015 12:07:53 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 105487 invoked by uid 89); 23 Jul 2015 12:07:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-ig0-f172.google.com Received: from mail-ig0-f172.google.com (HELO mail-ig0-f172.google.com) (209.85.213.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 23 Jul 2015 12:07:51 +0000 Received: by igr7 with SMTP id 7so92219003igr.0; Thu, 23 Jul 2015 05:07:49 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.12.104 with SMTP id w101mr12181079ioi.110.1437653269137; Thu, 23 Jul 2015 05:07:49 -0700 (PDT) Received: by 10.107.21.1 with HTTP; Thu, 23 Jul 2015 05:07:49 -0700 (PDT) Date: Thu, 23 Jul 2015 12:20:00 -0000 Message-ID: Subject: Re: [Bug fortran/52846] [F2008] Support submodules - part 3/3 From: Salvatore Filippone To: Paul Richard Thomas Cc: Damian Rouson , "Bader, Reinhold" , Fortran List , gcc-patches Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-07/txt/msg01930.txt.bz2 I agree with Paul that this is orthogonal to the compilation cascade phenomenon. In my opinion, putting PRIVATE entities in a module does not make much sense (yes, I know my example does it, but it is a quick adaptation of an existing code, not a clean design). If the main MODULE only contains the public interfaces, then all those PRIVATE entities really belong to the submodule together with the implementation(s) that use them. Even though within the submodule they can not formally have the PRIVATE attribute, they would still be invisible outside the submodule, therefore the end result would be the same. I have not yet enough experience to say whether I am totally comfortable with submodules as they are; however it seems to me that most of the doubts voiced so far depend more on programmer's discipline than on language facilities. Salvatore Il giorno gio, 23/07/2015 alle 10.37 +0200, Paul Richard Thomas ha scritto: > 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