Problem with Compilation Order

[stst]

I searched a lot in the internet, but i couldn't find a solution that worked for me, so here i am.

My problem is that we have a big project, which is old (started with Fortran77) and originally compiled on different compiler. Now we are using the Intel Visual Fortran Compiler XE 12.1.2.278 along with Visual Studio 2010.
It compiles fine, except for one problem. We have to compile our project 3 times for a successful compilation. ("Continue on Errors" is true)
We get a lot of errors like this:

error #7002: Error in opening the compiled module file. Check INCLUDE paths.
error #6404: This name does not have a type, and must have an explicit type.
error #6515: This function, which is specified as the left side of an assignment statement, is invalid.

Thats because the modules we are using are not yet compiled. So the compiler doesn't find the variables and procedures in those modules. After the first attempt, most of them are compiled. So the second time most of the errors are gone, because now the modules could be used successfully. The third try everything compiles just fine.

If the dependencies between the modules increases, so does the number of compiles we have to make.

In my opinion the USE-statements aren't correctly resolved. For example:

Module A uses Module B -> you have to compile Module B first, so you could compile module A
But in our case he tries to compile Module A. It fails, because Module B is not yet compiled. Then he compiles Module B, which is no problem, because it has no dependencies. If we start the compilation a second time, he can compile Module A, because he can use the already compiled Module B from our last attempt.

So what i already found:

http://software.intel.com/en-us/forums/showthread.php?t=77830
-> In my case every module has its own file and i don't use the module in the same file it was declarated.

http://software.intel.com/en-us/forums/showthread.php?t=73020
-> We have the same problem in another project which is much smaller.

I also checked for circlic dependecies, but i couldn't find any.
I have the feeling we are missing out a basic thing about how to make a big project in Fortran. Because otherwise everyone would have those problems.

Thanks in advance.

[Steven_L_Intel1]

This ought to work automatically. Most of the time when it doesn't there are circular dependencies. You can also try removing all the files from the project and re-adding them. If you still have problems, please provide us with a ZIP of the project and its sources. You can use Intel Premier Support for this if the project is large or you want it to be private. Please reference this forum thread if you do that.

[WSinc]

I have often found that when subroutine A calls subroutine B you have to compile subroutine B first if
you have made any changes to the interface between them.

In other words, the VS 2010 does not take the calling order into account when doing compilations.

Or at least not consistently each time.

[Steven_L_Intel1]

Bill, that's a different problem, though you are correct that the generated interface checking is not taken into consideration in the compilation order.

[stst]

I think I don't have circular dependencies, because the structure of our project is really flat. Half of the files are modules, which only contain variable declarations. The other half are files with just one procedure, which USEs the modules needed to access the variables inside.
There are hardly any "interface" or "abstract interface" declarations and there are no "include" statements at all.
As I said the code is ancient. In Fortran77 those features didn't exist.

I don't think there are circular dependencies, but I can't say it for sure. So I must ask the obvious question: "How do I track down circular dependencies?". In C++ there is a compiler switch to show you all include dependencies. I skimmed over the Fortran compiler options, but I couldn't find anything useful.

As you guessed I can't post any code, because of copyright issues. It would be too complicated anyway. But what I can do is make a small example to reproduce the problem. Maybe I can figure something out myself that way.
So I will provide an example by tomorrow morning.

[lklawrie]

1. You can have the compiler create a "make file" and examine it.

2. gfortran is pretty good about identifying circular dependencies, given a makefile but it's a bit hard to explain here.

3. If you do a lot of changes, we usually suggest that people step out of the IDE and back in -- to allow it to update the dependencies. CVF was famous for not obeying all the dependencies until you updated them all several times -- but IVF has been stellar in that regard.

[stst]

Ok, so here is my test project with the same error. It should be as minimal as possible.
I also tried it on a different computer, which was newly set up, to rule out that it is a local problem with my machine.

About the test project:
There are 4 files, which dependencies are like a diamond pattern.
Which namely means:

• base_mod has no dependencies
• code_mod and fcode are using base_mod
• and models1 is using code_mod and fcode

So the order in which the compiler wants to compile the files is the following:

1. models1.f90
2. fcode.f90
3. code_mod.f90
4. base_mod.f90

As you can see, the compilation order is totaly wrong, because he starts with the file which is dependent on all other files. A possible order would be:

1. base_mod.f90
2. code_mod.f90
3. fcode.f90
4. models1.f90

One thing I noticed while making this test project is that if i play around with the project filters the compilation order changes. That also applies if I rename files or modify the order of the files in the .vfproj with a text editor.

Note: If you want to compile the test project successfully you have to set the "Continue On Error" Option to "true". It takes 3 times until success.

[Arjen_Markus]

For some reason I can not download your zip file - my browser claims itcan not find the URL.
(I was simply wondering whether the problem occurs in VS 2008/Ifort 11.1as well)

Regards,

Arjen

[Les_Neilson]

I cannot download the file either.
I get the message "Can't find file 40794/"

Les

[stst]

Sorry, I just noticed that it doesn't work for me either.
After another try, it's the same. So here you go with an external provider:
http://www.mediafire.com/?8o6c29vm0azikg2

[Les_Neilson]

Setting build order applies to projects rather than files.
I suggest that you could create three projects within your solution :
(1) basemodproject witheverything that should be built first (i.e. base_mod.f90 in the posted code)
(2) othermodules project with files that may depend on basemod (i.e. code_mod.f90, fcode.f90)
(3) finalproj the project that uses the other two projects

Then in Project->Project Dependencies
under dependencies you specify that finalproj depends on basemod and othermodules
and othermodules depends on baseprod.

In this way the build will do things in the right order.

HTH
Les

[stst]

Thanks for your answer, Les.
What you suggest would definitly work. But such a solution only works well with small projects. On larger projects this would mean, you have to create hundreds of projects in a solution. That would be totally impractical.
To do this you also have to know every dependency in your project, which would be very difficulty. Let alone, if you change something, you have to do it all over again.

This would also mean you have to do something manually, what the compiler should do automatically.

As you can see this is no viable solution for me.

[Steven_L_Intel1]

I can reproduce the problem. Let me look into it further.

[Steven_L_Intel1 · Accepted solution]

Aha! The problem occurs when you use the :: separator in the USE statement. Apparently the project dependency checker is not recognizing the USE in that form. I will report it to the developers. Issue ID is DPD200177563.

As a workaround, remove the :: which is optional here. For the use of intrinsic modules, you have to leave the :: in but that doesn't matter.

[Les_Neilson]

Well I work with hundreds of projects. (over 500 vfproj files plus there are c/c++/c# projects) and over 350 solutions, which build libraries, dlls and executables.

The projects are organised into support libraries and executables.
We havea batch process which builds the libraries first ( and within that builds modules first)
Then the executables are built - linking in the libraries and/or using the modulesfor that executable.
Yes it is complex but once set up it just works.

If a change is made to the code within an executable solution only, then only that code is compiled and the exe built.

If a change is made to code in a library then that code is compiled, the library built then the exes that depend on that library are built.

In other words organise your code into manageable libraries (e.g. by directory). Each library would have its own solution file to build it.

{
my example :-
library/dps/util
library/dps/labels
library/dps/spfutil
etc.
each one has a solution/project which builds a lib file from the source in that directory.
}

Your main programs would be in other directories with solutions/projectswhich would have the above libraries as "Additional dependencies"

{
my example :-
drawings/fabs
drawings/fits
drawings/gaprod
etc.
each onecontains its own source code files andhas a solution/project which builds an exe linking in the libraries above.
}


Les

[lklawrie]

Your use of:

use :: base_mod

confused my automatic makefile generator. Perhaps it is confusing IVF as well?

[Steven_L_Intel1]

Linda,

Exactly - see my reply #13.

[stst]

I removed all the :: in all files and ... it works.
Ok, now i'm really surprised how easy that was.

I thought that the :: at the USE statement are generally used by everyone, because at variable declarations you also usually make ::
Maybe you've seen it in the example code, but we don't have a definite style guide for Fortran yet. That's mostly because it's a mixture between old and new code.

So, thank you very much for your help. I'm really relived that it it was such a trivial error. I thought that I have to overhaul the whole code, but now it was a matter of minutes.

[Steven_L_Intel1]

I expect this to be fixed in Update 9.