Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

How to rebuild an application without re-compiling all files in the project?

reidar
New User
2,850 Views

I am using Visual Studio 2013 with IVF XE 2013.

After that I have corrected something in a fortran text file, I press the F5 to recompile, link and debug. 

For some projects, only the file I have changed is recompiled, but usually all source files are recompiled even though no modification has been done. I find this time consuming and boring.

So I am thinking there might be a switch to be set somewhere  that tells Visual Studio that only files that are modified should be compiled?

Can anybody give me a clue?

0 Kudos
13 Replies
andrew_4619
Honored Contributor II
2,850 Views

If there are dependencies such as a file contains a module used by other files you can get a build cascade. Vs checks and only builds what it needs to. I have seen Vs faults in projects the give unnecessary builds.

0 Kudos
Steve_Lionel
Honored Contributor III
2,850 Views

There is no control over the build dependency analysis. You're using a sufficiently old version that I am pretty sure there were issues with this that were fixed in later versions. I have not seen an unnecessary build cascade in several years (without some error on the part of the user, such as a circular dependency.)

What you can try is deleting the .SUO file (this is a hidden file so you'll have to enable viewing of hidden files in Windows Explorer). Sometimes that helps. Sometimes it's necessary to just create a new project and add the sources to it.

0 Kudos
GVautier
New Contributor II
2,850 Views

Are "modern" versions smart enough to avoid recompilation if there is only internal changes in procedure(s) code that doesn't change the content of the .mod file?

0 Kudos
andrew_4619
Honored Contributor II
2,850 Views

Vautier, Gilles wrote:

Are "modern" versions smart enough to avoid recompilation if there is only internal changes in procedure(s) code that doesn't change the content of the .mod file?

I think the answer to that is no. You need to use submodules to achieve that function. I also think the dependencies are all handled VS so it would not understand the Fortran changes, only if a file has changed and which files are dependant on it. I guess if intel had implemented modules in a different way (separating interface and implementation into different files) they could make a temp interface file and check against the old one and not update if the same but I guess that ship has already sailed…. 

0 Kudos
GVautier
New Contributor II
2,850 Views

So the method I use is to group relatively independent blocs of source files of my projects into isolated "thematic" libraries tha can even be reused in other projects.

Then For all projects, I use a common modules directory where I manually copy .mod files of the libraries if needed only.

It's the best I found to limit unnecessary rebuilds.

 

 

0 Kudos
andrew_4619
Honored Contributor II
2,850 Views

Vautier, Gilles wrote:

So the method I use is to group relatively independent blocs of source files of my projects into isolated "thematic" libraries tha can even be reused in other projects.

Then For all projects, I use a common modules directory where I manually copy .mod files of the libraries if needed only.

It's the best I found to limit unnecessary rebuilds.

 

 

I used to do such things but now that everything I own is in submodules ( a big job!) it saves me a lot of effort thinking about such things.

0 Kudos
jimdempseyatthecove
Honored Contributor III
2,850 Views

The use of sub-modules can reduce the need for recompilation.

This said, there is a different technique that can be used with current compiles as well as older versions of the compiler that pre-date sub-modules.

1) Separate the module pragmas from the rest of the modules. These generally do not change from build-to-build during development.
2) Separate the global, generally shared variables by all (most) procedures. These generally do not change from build-to-build during development. (Defer placing this with the pragmas until completion of development)
3) Separate the potentially many module contained procedures from other contained procedures. Closely related procedures can be kept in the same module. Note, shared module variables for each separation can be kept with those separations.
4) Avoid making and using a module that simply contains a list of USE all other modules as this will defeat your purpose of unnecessary re-compilation.

Note, this should be extended to separate the User Defined Typetype/class declarations from their contained methods/procedures.

Jim Dempsey

0 Kudos
GVautier
New Contributor II
2,850 Views

In an ideal world, an option would exist to tell the compiler to update the existing .mod file if any only if there's changes to apply.

 

0 Kudos
Steve_Lionel
Honored Contributor III
2,850 Views

As Jim says, this is what submodules were designed to help. At present, any source file that changed since the last compile will be rebuilt, but if it's a submodule (that contains the implementation), that won't trigger recompiles of other sources that use the parent module.

0 Kudos
JohnNichols
Valued Contributor III
2,845 Views

As Jim says, this is what submodules were designed to help. At present, any source file that changed since the last compile will be rebuilt, but if it's a submodule (that contains the implementation), that won't trigger recompiles of other sources that use the parent module.

Actually this is not true with the latest VS and Fortran. If I add a parameter to a routine in Source1 and the same parameter to the call in Source2 they are not automatically building, I need to manual build.  Been happening for about 2 weeks.  Gives an interesting access error, 

0 Kudos
reidar
New User
2,850 Views

Hi All,

The reason why I asked in the first place:

I worked with a project that finished 2016 and then, let’s say version “A” of the application was relased.

To continue with a next version “B” of the application, I just copied the folders and renamed it.

I also renamed the .vfproj and the .sln file. Other files were renamed as changes/extensions  were introduced.

 

Now to the point:

If I open project  A.vfpoj  and I add and remove som text sommwhere in a source “S1.FOR”file, just to introduce a change. Then I press F5 and VS claims the project is out of date and ask about rebuild.

If I accept, sourcefile S1.FOR and only S1.FOR is compiled and the application is build and start in debug mode.

If I exit the debug mode without having introduced any modificataions, start again, the program just start running.

And this is on contrast to version “B”, the recent version of the project.  When I press F5 to start debug, VS claims the project is out of date.  Then all source files are recompiled and linked.

If I then exit without having done anything else then Shift+F5 to stop and then pressed F5 to start again, VS will again claim that the project is out of date end need to be rebuilt.

What is the reason why VS behaves different when dealing with two more or less identical projects?

Again I think this is a VS topic rather than a Fortran issue?

0 Kudos
jimdempseyatthecove
Honored Contributor III
2,850 Views

If I were to guess, it would be that the newer B solution is referencing (some of) the A solution files in its dependency walk.

To correct this, you may need to create, from scratch, a new set of solution and project files.

An alternate, and possibly more risky, approach is to edit the project and solution files directly (these are in html format) to find and change any and all cross linked paths.

Jim Dempsey

0 Kudos
reidar
New User
2,850 Views

I follwed your suggestion Jim and created a new set of solution, but still the same things happens. And as I have written before: 

Even  "If I then exit without having done anything else then Shift+F5 to stop and then pressed F5 to start again, VS will again claim that the project is out of date end need to be rebuilt. "

 

 

0 Kudos
Reply