Bug 35707 - Search /usr/local/include and /usr/include for .mod files
Summary: Search /usr/local/include and /usr/include for .mod files
Status: REOPENED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: documentation
Depends on: 49138
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-26 14:18 UTC by Tobias Burnus
Modified: 2013-06-20 14:27 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2009-03-28 15:46:26


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2008-03-26 14:18:00 UTC
Other compilers such as g95, NAG f95 and ifort also search /usr/local/include and /usr/include for .mod files (and "INCLUDE"d files).

I think gfortran should do the same, especially since #include searches these paths and "man gfortran"'s -Idir description implies #include and include search the same directories.

g95 seems to use libcpp for reading almost all files and thus it searches also in /usr/include (cpp_create_reader, cpp_read_main_file etc.). That way one could also cpp-preprocess files included via "INCLUDE" rather than via "#include".

The system include path is in the variable GCC_INCLUDE_DIR, which does not seem to be used outside of cpp unless I missed something.

For CPP work, see wiki:
http://gcc.gnu.org/wiki/GFortran44
Comment 1 Daniel Franke 2008-03-28 23:19:25 UTC
Implementation of this request should be trivial. IIRC just add the paths as arguments to -I options in lang-spec.h.


> That way one could also cpp-preprocess files included via "INCLUDE" 
> rather than via "#include".

I'm not happy with this idea. If a file should be preprocessed, the preprocessor should explicitly be told to do so. I.e. by passing the -cpp flag together with the main file, or by including files using '#include'. The INCLUDE-statement is defined by standard Fortran and Fortran (in general) has no concept of preprocessing. Hence, files included by the INCLUDE-statement should not be preprocessed, even if the main file is. That is: preprocess main-file, preprocess '#include'd files, include INCLUDE files after prepreocessing took place, but without preprocessing the INCLUDEd file itself.
Comment 2 Daniel Franke 2008-04-06 00:20:20 UTC
Related: PR35055
Comment 3 Joe Krahn 2008-05-08 18:19:00 UTC
Fortran files should not be put into /usr/local/include or /usr/include. Those directories are defined for C headers. It is particularly bad to put binary files there. We should instead develop a standard location for Fortran-specific files, as is done with all non-C languages. For example: /usr/lib/gfortran/modules /usr/local/lib/gfortran/modules.
Comment 4 Francois-Xavier Coudert 2008-05-14 10:48:11 UTC
(In reply to comment #3)
> Fortran files should not be put into /usr/local/include or /usr/include. Those
> directories are defined for C headers. It is particularly bad to put binary
> files there.

You're confusing module files and included files. Noone's talking about module files here.

> We should instead develop a standard location for Fortran-specific
> files, as is done with all non-C languages. For example:
> /usr/lib/gfortran/modules /usr/local/lib/gfortran/modules.

For modules files, this is not enough: they depend on compiler and compiler version, so you need at least /usr/lib/gfortran/4.4.0/modules, at least. But module files are not intended to be used system-wide, really.
Comment 5 Daniel Franke 2008-08-18 20:56:05 UTC
Reminder: libbackend.a(cpp_include_defaults) seems to be the place where standard include paths for targets are available -- including, but not limited to, /usr/include.
Comment 6 Daniel Franke 2008-12-07 19:38:18 UTC
Since libcpp integration, default search paths (i.e. /usr/local/ etc.) are used for #include'd files.

To add the default paths defined in gcc/cppdefault.c (cpp_include_defaults) to the module/INCLUDE search path, one could clone gcc/incpath.c (add_standard_paths) and call gfc_add_include_path() instead of add_path().

Tobias, do we still need/want this?
Comment 7 Tobias Burnus 2008-12-08 11:33:45 UTC
(In reply to comment #6)
> To add the default paths defined in gcc/cppdefault.c (cpp_include_defaults) to
> the module/INCLUDE search path, one could clone gcc/incpath.c
> (add_standard_paths) and call gfc_add_include_path() instead of add_path().
> 
> Tobias, do we still need/want this?

Good question. FX and Joe don't like the idea, but Fortran files (".h"/".inc" and ".mod" files one can find in /usr/include in some Linux distributions.

openSUSE has a .mod file and *.inc for NetCDF in /usr/include. The place for the .mod looks wrong, but for .inc?

A semi-proper place for .mod files is:
  /usr/lib64/gcc/x86_64-suse-linux/4.4/finclude/
(Semi because finclude does not distinguish between e.g. 32bit and 64bit.)
Comment 8 Daniel Franke 2008-12-08 12:50:38 UTC
> A semi-proper place for .mod files is:
>   /usr/lib64/gcc/x86_64-suse-linux/4.4/finclude/
> (Semi because finclude does not distinguish between e.g. 32bit and 64bit.)

One could argue that .mod files are library support files and could be placed/distributed in a project's $libdir?! If there's a difference between 32-bit and 64-bit .mod-files, placing them in their respective $multilibdir would solve this.
Comment 9 Mikael Morin 2008-12-08 14:25:05 UTC
(In reply to comment #7)
> A semi-proper place for .mod files is:
>   /usr/lib64/gcc/x86_64-suse-linux/4.4/finclude/
> (Semi because finclude does not distinguish between e.g. 32bit and 64bit.)
> 
Isn't (...)/x86_64-(...) enough to tell that it is 64 bits (besides /usr/lib64) ?

My opinion is that the proper way to distribute fortran so-called "headers" is via interfaces in fortran files, not via modules. 
If we add a "standard" place for fortran modules, everybody will use it, and it will raise countless problems (need to provide several modules versions for different compiler versions, doesn't work if the compiler is upgraded, ...)

In short, I agree with FX. :)
Comment 10 Daniel Franke 2009-01-03 23:26:44 UTC
(In reply to comment #7)
> Good question. FX and Joe don't like the idea, but Fortran files (".h"/".inc"
> and ".mod" files one can find in /usr/include in some Linux distributions.

Whoever requires .mod files probably has a Makefile around anyway - adding -I/usr/include is not exactly much to ask for.

I also think we shouldn't search the system paths by default.
Comment 11 Daniel Franke 2010-05-02 14:03:01 UTC
Consensus seems to be: no, do not search the system include paths.

Set status to WAITING. To be closed as INVALID(?) in three months from now if there is no further discussion.
Comment 12 Tobias Burnus 2010-05-02 14:32:03 UTC
(In reply to comment #11)
> Consensus seems to be: no, do not search the system include paths.
> 
> Set status to WAITING. To be closed as INVALID(?) in three months from now if
> there is no further discussion.
> 

Shall this be noted in the man page? It currently reads as follows which implies that "include" and "#include" are strongly tied?

       -Idir
           These affect interpretation of the "INCLUDE" directive (as well as of
           the "#include" directive of the cpp preprocessor).

           Also note that the general behavior of -I and "INCLUDE" is pretty
           much the same as of -I with "#include" in the cpp preprocessor, with
           regard to looking for header.gcc files and other such things.

           This path is also used to search for .mod files when previously
           compiled modules are required by a "USE" statement.
Comment 13 Daniel Franke 2010-05-09 19:41:11 UTC
(In reply to comment #12)
>        -Idir
>            These affect interpretation of the "INCLUDE" directive (as well as
> of
>            the "#include" directive of the cpp preprocessor).
> 
>            Also note that the general behavior of -I and "INCLUDE" is pretty
>            much the same as of -I with "#include" in the cpp preprocessor, with
>            regard to looking for header.gcc files and other such things.
> 
>            This path is also used to search for .mod files when previously
>            compiled modules are required by a "USE" statement.

Yes, I think that this text needs an update.
Comment 14 Dominique d'Humieres 2013-06-20 10:22:31 UTC
> Set status to WAITING. To be closed as INVALID(?) in three months from now if
> there is no further discussion.
> 

No progress three years later, closing as WONTFIX. Please reopen if you disagree.
Comment 15 Tobias Burnus 2013-06-20 10:29:53 UTC
(In reply to Daniel Franke from comment #13)
> Yes, I think that this text needs an update.

I concur that we - still - need a better documentation on this. It's related to PR 49138 where one defined a proper location for .mod files.
Comment 16 Dominique d'Humieres 2013-06-20 14:27:49 UTC
(In reply to comment #15)
> (In reply to Daniel Franke from comment #13)
> > Yes, I think that this text needs an update.
>
> I concur that we - still - need a better documentation on this. 
> It's related to PR 49138 where one defined a proper location for .mod files.

IMO the main problem with .mod files is that the version numbers are changing (too) often. Unless this is fixed, I don't see the point to have a hard coded path to search them.

In top of that having two PRs opened for almost the same topic is probably one too many.