allowable number of (fortran source code) files in a project workspace/solution?
i program in Fortran 90.
i'm using Intel Visual Fortran Composer XE 2011 for Windows (IVFCXE), on a laptop with specifications:- core i7, 8GB RAM, 1.2TB HDD (windows 7professional, 64-bit) -- my laptop is less than 1 year old.
i'm writing a program/project that consists of many files -- all of these files contain fortran source code. basically, there is 1 mainprogram, and then LOTS of subroutines. each subroutine is stored in it's own module (for ease of writing/managing the project). in regard toIVFCXE, the 'project' consists of a single 'project workspace' in a single 'project solution'.
so far:- 1) there are about 50 files (the whole project is not yet complete -- i'm testing each of the files as i go along); 2) the project compiles/builds ok, and all calculations seem to be working correctly; 3) my computer has handled theproject quite easily.
but, i've still got a long way to go, such the 'completed' project could contain a few hundred such files (100-200, or more, say).
my questions are:
1) is there a limit on the number of (fortran source code) files allowed in a single project workspace/solution?
2) if so, then what is this limit?
3) also, where can i find further information about this?
I also loosely follow the one routine per module/file for many reasons. So far over 1000 files in one project.
Since IVF does not support object browsing in Visual studio the next best thing is a tree of source folders organised by function.
But I am far from happy with this situation and do wish Intel would give more time to develop the IDE so we can browse the source more easily. Some other vendors already have this and indeed DVF already had some bits of it done, such as right clicking names to find their definition
Having seperate source for each routine can reduce compilation cascade but I also I think sub-modules should be high on the development list.
i know what you mean, about grouping 'like' files.
i'm currently working on a research report, for which i'm writing a fortran program, in order to support the report's concepts/theory. the reportitself is relatively simple. so much so, that, so far, i've spent far more time on the fortran program -- working out a 'system' of consistentfile-naming (for subroutines, type structures, 'global' modules, etc) and overall program layout, so that all 'like' files are grouped together.this way, as you said, my program is easy to read/understand in the long-run.