Fixing dependencies in vfproj

[Simon_Geard]

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

qsort_m.f90: qsort_m.fi

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

Thanks,

Simon

Code

qsort_m.f90
[fortran]
module qsort_m
    use iso_fortran_env
    implicit none
    
    interface qsort
        module procedure qsort_i2
        module procedure qsort_i4
    end interface

contains

#define TEMPLATE_TYPE integer(int16)
#define TEMPLATE_NAME(x) x ## _i2
#include 'qsort_m.fi'
#undef TEMPLATE_TYPE
#undef TEMPLATE_NAME


#define TEMPLATE_TYPE integer(int32)
#define TEMPLATE_NAME(x) x ## _i4
#include 'qsort_m.fi'
#undef TEMPLATE_TYPE
#undef TEMPLATE_NAME

end module qsort_m
[/fortran]

qsort_m.fi

[fortran]
#ifndef TEMPLATE_TYPE
#error "No TEMPLATE_TYPE defined - you can't use this code on its own, it has to be included in a module"
#endif

#ifndef TEMPLATE_NAME
#error "No TEMPLATE_NAME defined - you can't use this code on its own, it has to be included in a module"
#endif
 
     subroutine TEMPLATE_NAME(qsort)(a, perm)
!DEC$ ATTRIBUTES DLLEXPORT::TEMPLATE_NAME(qsort)
        TEMPLATE_TYPE, intent(inout) :: a(:)
        integer, intent(inout), optional :: perm(:)

        call TEMPLATE_NAME(qsort)_i(a, 1, perm)

    end subroutine TEMPLATE_NAME(qsort)
[/fortran]

[Steven_L_Intel1]

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?

[Simon_Geard]

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)? Thanks.

[Steven_L_Intel1]

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.

[Simon_Geard]

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.

[Steven_L_Intel1]

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

[Simon_Geard]

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, Simon

[Steven_L_Intel1]

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.

[Simon_Geard]

Thanks for that idea. I have moved the module into a new file 'generic_sort_test.fi' 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. Simon

[Steven_L_Intel1]

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

[Simon_Geard]

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