Clean Project

[dannycat]

When I modify the number of arguments in a subroutine I often get argument mismatch errors when I try to rebuild a solution. Even using the Clean Project does not solve the problem. What appears to be happening is that the interface checking .f90 files are not updated when the subroutine is changed and also these file are not removed by the Clean command. You have to locate the two files associated with the interface check and manually delete them. I suspect the reason for this is that these files are not included as part of the project.

Is there a cleaner way to avoid this problem that I am missing or should there an additional command added to the developer studio to fix this?

[DavidWhite]

Quoting - dannycat

When I modify the number of arguments in a subroutine I often get argument mismatch errors when I try to rebuild a solution. Even using the Clean Project does not solve the problem. What appears to be happening is that the interface checking .f90 files are not updated when the subroutine is changed and also these file are not removed by the Clean command. You have to locate the two files associated with the interface check and manually delete them. I suspect the reason for this is that these files are not included as part of the project.

Is there a cleaner way to avoid this problem that I am missing or should there an additional command added to the developer studio to fix this?

I think this issue is caused by automatically generated procedure interfaces. If you turn off the automatic generation of interfaces, and provide your own explicit interfaces when required, you may avoid this issue (try searching the forum for generation of interfaces to read more about these issues).

The generate interface blocks option is in Project Properties / Fortran / Diagnostics

Regards,

David

[Paul_Curtis]

First, I hope you are actually referring to Visual Studio, as DevStudio is very old; if you're still using DevStudio, you need to upgrade.

When you change a subroutine's arg list, clearly you need to manually track that change in all references to that subroutine. VS (not IVF) does a whole-project dependency analysis, so that any rebuild should trigger recompiles of all modules dependent on whatever was changed, and a complete rebuild should recompile everything, and in the correct dependency order. If a complete rebuild (clean + build) does not work, then you should create a new project and manually add the source files to that project (which is easy since files can be tagged in bulk). I have worked through many problems with the dependency checker, and found that starting a new project is the only thing that solves this issue.

[dannycat]

I am using VSand my "Solution" consists of 36 separate projects. I would expect the dependency checker to address the automatic interfaces when performing a build. It appears not to pick up on the fact that a function/subroutine in one project is dependent on the project containing the actual function and only relates to module dependencies. The suggestion of doing a Clean All and Rebuild All may not always work because the generated interface files are not deleted by Clean and it coud be that they are not regenerated if they already exist even if they don't match the actual arguments in the revised function.
Paul's suggestion will work but would take several hours to acheive with this particular application, so I'm sticking with my crudemethod for the time being.

The main reason for mentioning this of the forum is to:

1)hopefully give other users some information regarding this issue as (from my experience) it was very frustratiing when it first happens because you don't know why (All your routines have correct arguments but you still get error messages!).

2) Hopefully get the IVF development team to come up with afix for this problem.

[Steven_L_Intel1]

So noted. I agree that the dependency checker should take into account generated interfaces.