@urbanjost - yes, by ‘under windows’ I mean with native windows tools. We have developed a Fortran analysis and restructuring tool with many users, and some of them will want to use native Windows.
We are using ifort, gfortran and vms, and for some debugging cases, SunStudio and CVF. Let me explain what we are doing:
We have two current projects (though there will always be more). One is a migration of a power distribution code from VMS to Linux. There are about 4,000 files. The original code builds under VMS, with the VMS compiler, and makes heavy use of libraries. There are perhaps a hundred programs, communicating through shared COMMON blocks. Most of the code is an extended FORTRAN 77 style, but there are sections written in Fortran 95 or later. We can process the entire code in one pass, but it would sometimes be useful to process individual programs separately. We therefore wrote a handler which can find all of the modules, subroutines and functions, and all of the include files required for a specific program. This handler works under Linux and uses EXECUTE_COMMAND_LINE to launch find and grep commands to search for the required files.
The second project is an environmental code with about 20,000 files in 2,300 directories. However it doesn’t use all of them. Happily this is modern Fortran. Again, we can analyse the whole thing, but there are duplicately named sub-programs and modules and sorting them all out is difficult. The tool we have should do this under Linux (though we still have a little work to do for this one). One of the users definitely uses Windows. Hence the original question.
Three details:
i. I would prefer not to have to open 17,000 files under Fortran to chase the dependencies. @Arjen, I am not sure how stdlib would help - please can you explain?
ii. Most of the objects linked are linked from libraries. Watching to see what the compiler compiles won’t help us.
iii. We could find the include file names from the include statements in the code (in fact, that is what fpt does) but this won’t help with functions and subroutines. We have to search the code for them. Hence the rather extravagent grep commands in my original post.
There are, by the way, at least a couple of death-traps in the analysis. A function can be passed to another routine as a sub-program actual argument. That routine may invoke it using the formal argument name. A simple analysis won’t find this. For this reason we use the fpt front-end to search for sub-programs. There are also several different ways to reference an include file:
INCLUDE ‘foobar.inc’ ! Standard and sensible
#include “foobar.inc” ! Very common
INCLUDE foobar.inc ! No string delimiters - legacy
INCLUDE ‘(foobar)’ ! Where the compiler adds the extension and removes the brackets.
So: is there a native Windows equivalent to find and grep, or another, and perhaps better way to solve the problem?