Module name vs. File name

[ferrad01]

I have a project containing many modules, one per f90 file. As of yesterday the name of the module was the same as the name of the file. All compiled and linked perfectly. Then I decided to rename the files, to make them shorter and simpler. Now my project will not build. It stops on the first file it's trying to compile:

D:sim2008.1A_Intelgss_medusa ep_summary_open_close.f90(15) : Error: Error in opening the compiled module file. Check INCLUDE paths. [M_DATA_STRUCT_SUMMARY]

It appears that it is looking for the module M_DATA_STRUCT_SUMMARY in the file m_data_struct_summary.f90 (as it was previously called), however I have renamed it.

As far as I am aware, the name of the file does not have to be the same as that of the module, so I am confused as to why this does not build.

[Steven_L_Intel1]

Try doing a Build > Rebuild

The name of the compiled module is based on the module name (from the MODULE statement) - the file name is irrelevant. It could be that there is some stale build dependence information that a rebuild should take care of.

[ferrad01]

I've tried Clean, Rebuild 100 times. It still wants to compile a file before compiling the module it depends on.

[ferrad01]

I copied all the files over again, restarted DevStudio, and now it's happy. Who knows...

[jimdempseyatthecove]

You may have a circular dependency or a dependency order not specified (and the order chosen by VS is not the order required).

I have a problematicsolution file where I cannot get the dependencies in the correct order. Luckily for me I can get the solution to build with 1, 2 or 3 requests to build.

I too have noticed that if you create a new solution, which has everything the faulty solution has, that it will often build correctly. This will work for many months, then something creeps in and then the dependencies get goofy again. I've learned to live with it as MS cannot seem to reproduce the problems.

I also have an issue where I get in a state where I cannot start in Debug mode (F5), I get Illegal Memory Access. However, If I step into (F11), usualy I get into the C runtime startup, then F5 will continue to first Break Point. When F11 no longer works, I must exit VS and restart VS, this seems to get F5 working again. Exit/Restart VS takes a long time so I tend to do that as infrequently as possible.

Jim Dempsey

[Les_Neilson]

I haven't (yet)experienced your F5Illegal Memory Access problem but I often havethe situation where F11 will hang VS and I either have to kill it or it eventually dies asking me if I want to send a message to Microsoft (I did a couple of times but heard nothing back so I gave up)
If I manually load the routine I want to step into and set a break point at the first executable statement then VS will work fine until it decides some time laterto die on anotherF11 somewhere else. :-(

Les

[jimdempseyatthecove]

Les,

The F5Illegal Memory Access problem occurs in Devenv (the VS Development Environment) prior to reaching the C0 startup code. So placing a break point at the entry of the program will not circumvent the problem. Why F11 (Step Into) works, I have no clue, but it works most of the time. When it won't, I either must exit VS and restart VS (takes about a minute). A real PIA

Jim