[patch, fortran] output of Makefile dependencies

[Daniel Franke]

On Sunday 13 June 2010 15:47:52 Tobias Burnus wrote:
> a) You need to change invoke.texi, it still lists -M as (deprecated)
> synonym for -J.
>
> b) gfortran.texi lists:
>   @item
>   Flag to generate @code{Makefile} info.
> You should remove it.
> (By the way, the "Proposed Extensions" and "Fortran 2003 and 2008
> status" sections need to be updated badly.)

Shall have a look.


> c) The patch does not work properly.
[...]
> $ gfortran -cpp -I./x -M inc.f90
> inc.o m.mod: inc.f90 other.f90 iso_c_binding.mod iso_c_env.mod \
>  omp_lib.mod omp_lib_kinds.mod
> 
> Expected:
> 
> - other.f90 misses the path "./x" in the name (it works for #include
> "other.f90").
> 
> - The intrinsic modules "iso_c_binding.mod", "omp_lib.mod", and
> "omp_lib_kinds.mod" shall not be listed - only the non_intrinsic module
> "iso_c_env.mod".

Try -MM.
"Like -M but do not mention header files that are found in system header 
directories, nor header files that are included, directly or indirectly, from 
such a header."

Renaming "MODULE m" to MODULE iso_c_env", I get:

$ gfortran-svn -cpp -I./x -MM other.f90
other.o iso_c_env.mod: other.f90 other.inc iso_c_env.mod

However, the path component on other.inc is missing.
Also strange, the iso_c_env.mod depends on itself. Not ideal, I assume.

 
> - If possible: If - for instance - the "omp_lib.mod" file exists, add it
> to the list as the standard has
> "A use-stmt without a module-nature provides access either to an
> intrinsic or to a nonintrinsic module. If the module-name is the name of
> both an intrinsic and a nonintrinsic module, the nonintrinsic module is
> accessed."
> If the check can not easily be done, I think one can simply assume that
> the intrinsic module is meant - which is the most likely case.

Probably already handled by -MM as well. If the file is found in a user 
include directory the 'system' parameter of gfc_cpp_add_dep() is set to false.

Cheers

	Daniel