-gen-dep and intrinsic modules

[Izaak_Beekman]

Can I submit a bug report or feature request that the -gen-dep flag not include a bunch of compiler files when intrinsic modules are used? For example, I have a file that produces the expected dependencies when I do not use ISO_FORTRAN_ENV, but when I do use the intrinsic module it includes a bunch of stuff in /opt/ and /usr/ that is not a dependency of the code, because ISO_FORTRAN_ENV is an intrinsic language feature.

With ifort version 13.1.0.146, build 20130121, I run:

[bash]$ ifort -syntax-only -stand f08 -standard-semantics -gen-dep=kinds.d kinds.f90[/bash]

And from this I get the expected output:

[plain]kinds.mod : \
  kinds.f90

kinds.o : \
  kinds.f90 debugging.mod[/plain]

Now if I add [fortran]Use iso_fortran_env ,Only: INT8 ,INT16 ,INT32 ,INT64 ,REAL32 ,REAL64 ,REAL128[/fortran] to the file, and I get dependencies that should not be included. See the attached files.

[Steven_L_Intel1]

You certainly can submit a bug report on this and you just did. I will let the developers know.

[Izaak_Beekman]

Hi Steve, has this been fixed yet? If so what release? I'm using 13.0.2 20130314 and I'm still getting a lot of strange things in the dependency listing. Also, an option to output modules that are provided by the source file as targets (along with the .o files) would be very helpful. (Otherwise make will see that foo.o depends on bar.mod but has no way of knowing how to generate bar.mod which might be in baz.f90.) So the dependency for baz.f90 would look like this:

baz.o bar.mod : baz.f90 other_dependencies.mod other_includes.i90 #etc.

[Steven_L_Intel1]

Sorry, not fixed yet.

[Izaak_Beekman]

is there a tracking number/id?

[Steven_L_Intel1]

Sorry, I missed telling you the tracking number, which is DPD200254019. We've made some improvements to this for the 15.0 release, but in the longer term will allow you to enable/disable including the "intrinsic" paths in the generated output.

[Izaak_Beekman]

Hi Steve,

What are the 15.0 improvements?

Being able to disable including “intrinsic”/internal modules/files/etc would be great. I don’t really see why the end user would want to include them, but I defer to your better judgement.

I would also like to ask for another two features regarding automatic dependency resolution:

1. Historically, the way to treat fortran dependencies has often been to just specify that one object file depends on one or more source files, as well as object files associated with source files that have modules in them. This just enforces that the codes are compiled in the correct order, but is a source of compilation cascades. A more modern way to treat dependencies, especially if the info is generated by the compiler (since the naming scheme—especially with capitalization—of the .mod files is compiler specific) would be to specify that the object file and any modules in the source file(s) are products of the compilation, and the only dependencies are the source file(s) and any USEd mod files. It would be great if there was a switch to control whether the .mod files appear explicitly as recipe dependencies and targets, or to use the older implicit module tracking, wherein object files appear as dependencies of other object files and no mod files are referenced. See for example makedepf90 which runs by default in the legacy mode (.o files only) but has a switch to check the modules: http://personal.inet.fi/private/erikedelmann/makedepf90/
2. Another great feature would be to enable the dependencies to be extracted in any order; don’t do any compilation or syntax checking, don’t require USEd .mod files to be present. To generate the dependency info, you only need to know about INCLUDEd source files and modules provided and consumed. This would go a long way towards speeding up Makefile builds. While GNUmake will recursively rebuild and recheck the makefile when it changes, this process is slow. Furthermore, additional speedup can be gained if the outputs don’t depend explicitly on the included dependency file, and the dependency file is rebuilt while the file is being compiled. If the dependencies change then the the makefile is out of date and will be rebuilt, triggering a rebuild of the target. See http://make.mad-scientist.net/autodep.html for more details on how to do this, and why it will speed things up.

[Steven_L_Intel1]

The improvement is to not include the extraneous paths to files that don't exist.

Submodules should help a lot with the compilation cascade issue.

[Steven_L_Intel1]

We've now implemented an option to allow you to select whether or not default include paths are considered in the dependency generation. This will go into a future major release.

[Izaak_Beekman]

Great news, I look forward to trying it.