Seeing Fewer Compilation Cascades

[Jacob_Williams]

Was there any special magic added to v2015 (or later) of the compiler to reduce compilation cascades when the source file for a module is changed?  I'm noticing instances where, when making a minor change to a routine inside a module, all the other modules that use it are not being recompiled.  The module in question is within a library that the main program is using.  The other modules within the library are being recompiled, but the modules in the main program that use it are not.  I'm pretty sure that formerly, all modules that used it would be recompiled.  I wanted to check here first to see if it was a new feature, or something I should be worried about.  (If it's a feature, it's a welcome one. I always thought that if the interface to a subroutine didn't change, then the mod file shouldn't change either. But, that's never how the compiler has behaved for me in the past).

[Steven_L_Intel1]

I am not aware of any changes here. The dependency checker doesn't look at interfaces. You will want the submodules feature when it appears.

If you can provide a test case, that would be helpful.

[IanH]

That's not new to 2015 - that behaviour has been around for a couple of years.  Files in other projects that reference a module are not recompiled when the source of the module is changed.  Note the recompilation of dependent files in other program units does not occur even when you do change the externally visible characteristics of the module in some way - you need to manually rebuild downstream projects from scratch in that instance. 

Be mindful that the externally visible characteristics of a module go further than just the immediate source code of  the interfaces of the public module procedures themselves - you also need to consider things like variables, constants, types and generic interfaces that the module exposes.  Changes to the interface of private procedures can also require recompilation of downstream code if those procedures are referenced in the specification part of a public procedure.

Edit to note that I'm not sure whether this is a bug, or a feature, or just the way things have to be given VS's project system - I can see benefit in pushing the need for manual recompilation back to the programmer for large enough units of code, but forgetting to rebuild downstream projects after a change seems to happen to me about once a day, and typically costs me ten minutes or so of pointless debugging until I realize what I've forgotten.  I'm starting to get in the habit of doing a solution wide rebuild before running anything as a result.

[Jacob_Williams]

Steve,

Can you confirm what Ian is saying in his first paragraph? This seems like a massive bug (basically making the dependency checker useless).  Was this an intentional change?  Is there any way to get back the old behavior?

[Steven_L_Intel1]

To be honest, I was not aware that this was the behavior. But I did a test and Ian is correct. I don't think this is "new behavior". I will talk to the developers and see if we can find a way to deal with this properly.

[Jacob_Williams]

Thanks!  I only just noticed this recently.  It's possible it has been like this for a while (I know I skipped a few updates due to some bug or another).  I would swear that the behavior used to be different.  I remember updating low-level modules in the library and having to wait for the entire program to recompile.

[IanH]

I have a similar feeling that things used to be different, but I suspect this behaviour has been around since/is as a consequence of the introduction of VS2010 - see https://software.intel.com/en-us/forums/topic/334790. ; Also https://software.intel.com/en-us/forums/topic/528757

If the Fortran integration has control over this aspect, allowing the behaviour to be controlled by a user option in the integration settings would be handy, regardless of whatever default Intel decides is appropriate.  Given the compile time associated with Fortran compilation cascades makes some people antsy I can see arguments both ways.

[Jacob_Williams]

Interesting!  Your first link jogged my memory.  I had removed the library module directory from the "Additional Include Directories" field back in December during some VS solution cleanup when I noticed that the compiler was already adding it.  Sure enough, when I add it back, I get the "old" behavior again (the higher-level modules are getting recompiled across projects when the lower-level ones are changed).  Since this is what I want, I'll leave it, but it does seem like using one bug to work around another! 

FYI: I notice that the paths I'm adding are using the / slash and relative paths, while the ones the compiler is adding use the \ slash and absolute path.  Maybe that is somehow causing the difference?

[Steven_L_Intel1]

Ah, the automatic adding of include for dependent projects may indeed be relevant. I did test this with VS2008 and saw the bad behavior, but this is with auto-include. I will try again with adding the explicit include. If that's what it is, it's probably easy to fix.