How many times do I have to run ifort to compile in cmd

[balabi_b_]

I used to use command line to compile my fortran file.

usually, there are several fortran source file in my working directory, and here is how I compile them

1. open cmd and switch to the working directory
2. ifort *90 /Qmkl   !!this step will generate object file and mod files
3. ifort *90 /Qmkl  !! 2nd time it will generate the .exe file

Sometimes I also use MPI, so mpiifort *90 /Qmkl

My question is, if I now edit one or several source files, how many times do I have to run ifort or mpiifort? twice or just once (I found once seems working)? and why?

[Simon_Geard]

Just once should be enough (your step 3) provided you use the correct order for your source files; *.f90 is almost certainly not what you want. The files are compiled from left to right on the command line and in order to build in a single pass that order must honour the module dependencies, so that all modules used by a procedure have already been compiled. Of course if you have circular dependencies this will alway fail but that is a different problem.

I use the command line to build stand-alone versions of the code for testing but in that I compile all the source code except the main program with the /c switch then pass the .obj files to the final build step:

del /s /q *__genmod* *.mod *.smod *.pdb *.obj
rmdir /s /q x64
if "%~1"=="clean" exit /b
mkdir x64
set FOPTS=/nologo /fpp /debug-parameters:used /warn:declarations /debug:full /Od /check:bounds /check:uninit /Qtrapuv /assume:realloc_lhs /D_DEBUG
ifort /c %FOPTS% /Fox64/mod1.obj mod1.f90
ifort /c %FOPTS% /Fox64/sub1.obj sub1.f90
ifort %FOPTS% main.for x64/mod1.obj x64/sub1.obj

In practice I have a text file containing the ordered list of source files that a (tcl) script reads and then creates a .bat file

[mecej4]

If your Step-2 failed to produce an EXE file, (i) you may have compile-time errors in one or more of the source files, or (ii) the compiler chose to compile the files in an order that did not generate a .mod file before it was USEd in another source file, or (iii) there were link-time errors. 

If Step-3 worked after you had completed Step-2, the indication is that there was just one module file that was not available when needed in Step-2. 

In general, as Simon hinted, if you have more complex module dependencies, many iterations of Step-3 may be necessary, and you should specify the dependencies in a makefile, a batch command file, or in the Visual Studio project files.

[balabi_b_]

Simon Geard wrote:

Just once should be enough (your step 3) provided you use the correct order for your source files; *.f90 is almost certainly not what you want. The files are compiled from left to right on the command line and in order to build in a single pass that order must honour the module dependencies, so that all modules used by a procedure have already been compiled.

Hi, Thank you for answering. You said the right order will demand only one run of ifort. But deciding dependency and order is annoying.

As I tested, running ifort once will update all the object, mod, and exe files, and shows no error. Since they are all newly generated, why they are possibly not right?

I would like to make sure, if I insist using "ifort *.f90", will compile twice guarantee the correct output of .exe? According to  mecej4's saying, it seems that twice is not alway enough, he said "many iterations of Step-3 may be necessary". But how many? Is there a judgement? If the final compile gives no errors and generate the executable, does it means a successful compilation?

[Brooks_Van_Horn]

I don't think it is necessarily related to the script files of balabi b. I have a similar problem with both the commandline compilations and links and MSVS 2013 with linking. From the command line my script for linking looks like:

call cmp %1
iFort %1.obj MyLib.lib c:\dislin\disifl_d.lib user32.lib gdi32.lib opengl32.lib

When I run this about every other time the link step says it cannot read (aka delete) the old exe file. MSVS has a problem updating the exe with the maniifest. After a couple of times telling it to rebuild with no other action on my part it succeeds. The only common thread is iFort. And it is the only application that has any issues with my system.

Brooks V

PS, it is only an inconvience since all I have to do is repeat the last step.

[Steven_L_Intel1]

What I find is it's virus scanners that lock newly-created executables so they can check for viruses. See if you can exclude your build area from on-access scans. Note that linking and the manifest tool are Microsoft tools, not part of Intel Fortran.  There is also an annoying issue with Visual Studio holding executables open after a debugging session - this affects C++ users too.