VS2013 strange behaviour/submodules/PSXE16.0

[andrew_4619]

I am making some tests with PSXE16.0 using SUBMODULES. My test job exhibits some strange behaviour:

1] On doing a successful build or clean then build if I do F5 to debug it says the exe is out of date and does a full build again. It will then debug.

2] On changing anything, e.g. the main program (there are only 3 source files ) is does a complete rebuild every time.

This type of behaviour I have experienced before when the project has circular dependencies. This project has three files, a module file with interfaces, a sub module file with only contained sub-routines and a simple main program. I did all the usual close VS and restarting, deleting the project and making a new one etc.

On opening the project in VS the first time and doing a build I get (one time only!):

C:\Users\...\fred_subs.f90 : warning: Module 'Debug\subroutine.mod' is created by both 'C:\Users\...\fred_subs.f90' and 'C:\Users\...\fred.f90'.
1>------ Build started: Project: SUBM_TEST2, Configuration: Debug Win32 ------
1>Compiling with Intel(R) Visual Fortran Compiler 16.0 [IA-32]...
1>fred.f90
1>fred_subs.f90
1>SUBM_TEST.f90
1>Linking...
1>Embedding manifest...
1>
1>Build log written to  "file://C:\Users\.....\Debug\BuildLog.htm"
1>SUBM_TEST2 - 0 error(s), 0 warning(s)
========== Build: 1 succeeded, 0 failed, 1 up-to-date, 0 skipped ==========

Note the first line! I think this is the route cause but it makes no sense are the VS integration picking up “module subroutine” which is part of the interfaces for each subroutine and also the definition and believing there is a MODULE called SUBROUTINE? “Subroutine.mod” is not created by the way.

Does anyone know of any issues like this? 

[OP1]

How did Santa do? The forced recompilation (even when no change is brought to the code!) is indeed pretty "horrendous".

[Steven_L_Intel1]

As Kevin said, Update 2 is planned for this quarter - early February.

[Kevin_D_Intel]

I confirmed two of the four internal tracking ids from post #11 have been fixed as noted below. The most serious of them (DPD200375984) has been fixed in the latest PSXE 2016 Update 2 Release.

I will post again as fixes become available for the remaining two issues.

(Internal tracking id: DPD200375967 - Source code collapse/expand feature not active for subprograms in a submodule) – Not fixed yet
(Internal tracking id: DPD200375981 - One-time warning: Module '<some>.mod' is created by both... for project containing submodules) – Not fixed yet
(Internal tracking id: DPD200375984 - Submodules cause full project rebuild after source code edit unrelated to the module or submodule) – Fixed in PSXE 2016 Update 2 Release
(Internal tracking id: DPD200375987 - Erroneous remark #7712 for submodule interface block) – Fixed for the next major release later this year

[Kevin_D_Intel]

To close on the remaining issues.

I confirmed the fix for DPD200375967 is in our PSXE 2016 Update 4 release; however, it is *not* in the latest PSXE 2017 release but I expect it will be in the PSXE 2017 Update 1 release in the coming weeks.

While I have not received an indication of a fix, I’m no longer able to reproduce the one-time build warning reported under DPD200375981. That’s true with PSXE 2016 Update 4 and PSXE 2017 initial release so it appears this may have been fixed as a by-product of other changes. I’ll inquire w/Development.

Also, I confirmed the fix for DPD200375987 is present in the PSXE 2017 initial release.

(Internal tracking id: DPD200375967 - Source code collapse/expand feature not active for subprograms in a submodule) – Fixed in PSXE 2016 Update 4
(Internal tracking id: DPD200375981 - One-time warning: Module '<some>.mod' is created by both... for project containing submodules) – Fixed in PSXE 2016 Update 4 and PSXE 2017 initial release
(Internal tracking id: DPD200375987 - Erroneous remark #7712 for submodule interface block) – Fixed in PSXE 2017 initial release