Fixing dependencies in vfproj

Fixing dependencies in vfproj

I have used the fpp to provide a templating mechanism for some sorting subroutine - code snippet at the end. The problem is that everytime I build the project the code is recompiled. It seems that the default dependencies are not correct but I don't know where or how I should change them. If I were writing a Makefile I would write something like:

qsort_m.obj: qsort_m.f90
       ifort -o qsort_m.obj -fpp qsort_m.f90


So how do I change the default dependencies in the vfproj file?





module qsort_m
    use iso_fortran_env
    implicit none
    interface qsort
        module procedure qsort_i2
        module procedure qsort_i4
    end interface
#define TEMPLATE_TYPE integer(int16)
#define TEMPLATE_NAME(x) x ## _i2
#include ''
#define TEMPLATE_TYPE integer(int32)
#define TEMPLATE_NAME(x) x ## _i4
#include ''
end module qsort_m

#error "No TEMPLATE_TYPE defined - you can't use this code on its own, it has to be included in a module"
#error "No TEMPLATE_NAME defined - you can't use this code on its own, it has to be included in a module"
     subroutine TEMPLATE_NAME(qsort)(a, perm)
        TEMPLATE_TYPE, intent(inout) :: a(:)
        integer, intent(inout), optional :: perm(:)
        call TEMPLATE_NAME(qsort)_i(a, 1, perm)
    end subroutine TEMPLATE_NAME(qsort)

11 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

You can't - the dependencies aren't recorded anywhere. Rather, they are computed anew for each build. Can you attach a ZIP of a project that shows this problem? What happens if you create a new project and add the files to it - do you get the same behavior?

Retired 12/31/2016

Thanks for the suggestion. I've create a new project and found that I can't reproduce the behaviour so I'll try to follow this up tomorrow. In the meantime is there any way to see why Visual Studio decides to rebuild them (like make -d)?


Unfortunately, there is no tool or logging available for this. If the problem does not show in a new project, then you may want to try deleting the .suo file in the solution folder (it is a hidden file so you may need to enable viewing hidden files to see it.) I am not sure if any dependency information is stored there, but it can't hurt. The file will get recreated - this also contains things such as breakpoints you may have set and debugging options.

Retired 12/31/2016

I have managed to isolate the problem into a project containing two files, the problem being that second and subsequent builds always compile the source code when in fact they shouldn't.


Downloadapplication/x-gtar srsdep.tgz3.85 KB

Thanks - I can reproduce the problem and will investigate it. I wonder if the use of the preprocessor is somehow involved...

Retired 12/31/2016

It's behaving as if the .obj or .mod files being generated aren't the ones that the build dependencies are expecting, but I can't devise a scenario in which the preprocessor could cause this problem,


I see what the problem is now. The way you have the project set up, module generic_sort is not generated. But the dependency analyzer sees the definition of the module and believes it needs to be built. It doesn't process all of the conditional compilation directives to see that it would be skipped. If you remove that module from the source, then you don't get the problem.

I will ask the developers if they can enhance the analyzer to process conditional compilation directives. I assume the one for C/C++ can do so. Issue ID is DPD200238979. Thanks for the example.

Retired 12/31/2016

Thanks for that idea. I have moved the module into a new file '' which is conditionally included and can confirm that second and subsequent builds no longer recompile the code. The only problem I've noticed is that the editor insists that the code is fixed format and since it is a '.fi' file there seems to be no way of disabusing it of this notion.


If you wish, you can change the interpretation of file types in Tools > Options > Intel Composer XE > Visual Fortran > General.

Retired 12/31/2016

I've tried that and it works as I'd hoped. Thanks for your help.


Leave a Comment

Please sign in to add a comment. Not a member? Join today