From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15816 invoked by alias); 24 Jun 2013 06:53:59 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 15734 invoked by uid 48); 24 Jun 2013 06:53:49 -0000 From: "Joost.VandeVondele at mat dot ethz.ch" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/40958] module files too large Date: Mon, 24 Jun 2013 06:53:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 4.5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: Joost.VandeVondele at mat dot ethz.ch X-Bugzilla-Status: REOPENED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-06/txt/msg01330.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40958 --- Comment #14 from Joost VandeVondele --- (In reply to Janne Blomqvist from comment #13) I believe a lot of progress has been made indeed. > However, the fundamental(?) issue of module sizes growing exponentially with > deep module hierarchies still remains. The solution to that is to not > include transitive dependencies, which in turn would require a module cache > for good performance. Whether that is worth doing, and who is willing and > able to do it, is unclear. note that there could also be disadvantages for that solution. For example, dependencies for a given .F would be more difficult to find (i.e. not just the USE statements). I'm not sure what implications that would have e.g. for 'smart' recompilation (i.e. based on time stamps of .mod). The module cache would also not work very well for the (common, I guess) case of having a single module per file, and all USE statements on top. It might thus be that the current state is the sweet spot.