Cleaning a solution

dboggs

Sat, 02/23/2013 - 15:29

We are trying to understand some odd apparently inconsistent compile behavior. The subject program calls an external subroutine that features an optional argument, and there is no explicit interface to it (the subroutine was designed to be in a module but that slipped through the cracks). Compiling the program produces warning #8055 about the missing interface (the warning may be promoted to an error depending on a VS setting, which only added to the confusion). If the VS option "Clean solution" is used, then the compiling and linking (and execution) works OK. But if any edit no matter how small (such as inserting a space then deleting it) is made in the source, the warning comes back, until it is again Cleaned.

Q1: What does this "cleaning" do? Does it make sense that it would temporarily fix the missing interface warning?

Q2: When is it safe or "good practice" to do this cleaning? In this case it appears to fix a problem--although awkwardly--while in reality it only masks a serious issue that really needs to be addressed differently (i.e. provide the interface or restore the module).

9 posts / 0 new

Last post

For more complete information about compiler optimizations, see our Optimization Notice.

app4619

Sat, 02/23/2013 - 16:26

From my experiance 'cleaning' just deletes all the temporary and intermediate files in the project folder and then the project then requires a complete rebuild. I occiasonally find dependnacies get messed up and a clean sorts it out. I can't explain your problem though.

Steve Lionel (Intel)

Sat, 02/23/2013 - 16:30

Cleaning a solution deletes files of particular file types from the project intermediate folders. You can see which files are deleted by looking at the project property General > Extensions to Delete on Clean.

The behavior you note is because the generated interface module files, xxx__genmod.mod, are deleted on a clean, and the presence of these is what is used by generated interface checking. The next time you build, if the source that calls the routine happens to be compiled before the source that defines the routine, you won't see the generated interface error. But once that module is there, subsequent compiles will see the error.

You should correct the error in your sources. It would be better if the build order tried to take generated interfaces into account.

Steve

app4619

Sun, 02/24/2013 - 14:25

That explains one or two strange behaviours I have had from time to time. Thanks.

IanH

Sun, 02/24/2013 - 17:16

A warning for an implicit procedure reference would reliably trigger for the programming error in the original post too...

<nudge target="Intel Fortran developers" class="subtle">.

dboggs

Mon, 02/25/2013 - 09:22

Thanks for the info on cleaning. Now it makes sense.

But I would like some clarification on the "error" itself. The lack of an explicit interface appears to be only a "warning" which, if I choose, can be treated as an "error" and thus prevent successful compiling until it is fixed. If I don't choose this setting, it remains a warning only and the program compiles, links, and runs just fine. What is the risk of depending on this, i.e. what exactly does a warning mean? Is it an Intel extension to the standard that allows the program to compile and run? Is it only if I want complete conformance to the Fortran standard that the "error" has to be fixed?

And if the offending subroutine (having an optional argument) is put in a module, and the resulting .mod file is added to the project, ist that a perfectly good way of fixing the problem? (I would consider this easier than adding an explicit interface to the calling program.)

Steve Lionel (Intel)

Mon, 02/25/2013 - 10:26

The warning means "We're compiling this, but it may not do what you want". At run-time you're likely to get an error or incorrect execution.

Steve

MVR M.

Sun, 03/03/2013 - 17:20

I am new to Intel fortran Composer XE 2013. I would like to know what is a Project and a solution.

2) If I want to create different versions of an exe file by changing a a few things in a source code of one sub routine among many sub routines and give different names to the exe files, How do I go ahead? Do I need to copy all the subroutines etc arranged in a folder as two places and use the seperately ( Whereas all the changes will be only in one of the subroutines, among several that are linked). Please advise me the best possible way to go ahead.

Regards

Steve Lionel (Intel)

Sun, 03/03/2013 - 17:45

1) A project builds a single executable or library. A project is for one programming language only. A solution is a container for one or more projects - if you build the solution, you build all projects in it. Build order is determined by project dependencies that you can establish. Visual Studio always wants to create a solution when you go to build a project. For a simple application, a solution will contain a single project, but it can have many, including projects in different languages (say, C++ and Fortran) that are combined when the top-level project is built.

2) You can create multiple "configurations" of a project with different settings. Typically I'd suggest using preprocessing to make the changes in the source files, and you can then specify the values of the substitutions in the "Preprocessing" property page of the configuration. You can also change the executable name in the configuration property.

Steve

Back to original post

Intel® Developer Zone

Cleaning a solution

Cleaning a solution

Login to leave a comment.