Fixing dependencies in vfproj

Fixing dependencies in vfproj

imagem de sgeard@cad-schroer.co.uk

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

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

qsort_m.fi

#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)

11 posts / 0 new
Último post
Para obter mais informações sobre otimizações de compiladores, consulte Aviso sobre otimizações.
imagem de Steve Lionel (Intel)

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?

Steve
imagem de sgeard@cad-schroer.co.uk

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.

imagem de Steve Lionel (Intel)

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.

Steve
imagem de sgeard@cad-schroer.co.uk

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.

Anexos: 

AnexoTamanho
Download srsdep.tgz3.85 KB
imagem de Steve Lionel (Intel)

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

Steve
imagem de sgeard@cad-schroer.co.uk

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

imagem de Steve Lionel (Intel)

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.

Steve
imagem de sgeard@cad-schroer.co.uk

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

imagem de Steve Lionel (Intel)

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

Steve
imagem de sgeard@cad-schroer.co.uk

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

Simon

Faça login para deixar um comentário.