[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707
Bug 35707 depends on bug 49138, which changed state.
Bug 49138 Summary: Add /usr/include/fortran/{,gcc-} to the file/module
search path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49138
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |DUPLICATE
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707 --- Comment #17 from Dominique d'Humieres --- *** Bug 49138 has been marked as a duplicate of this bug. ***
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #14 from Dominique d'Humieres dominiq at lps dot ens.fr --- 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.
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Depends on||49138 Resolution|WONTFIX |--- --- Comment #15 from Tobias Burnus burnus at gcc dot gnu.org --- (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.
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707 --- Comment #16 from Dominique d'Humieres dominiq at lps dot ens.fr --- (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.
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
--- Comment #13 from dfranke at gcc dot gnu dot org 2010-05-09 19:41 --- (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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
--- Comment #11 from dfranke at gcc dot gnu dot org 2010-05-02 14:03 --- 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. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
--- Comment #12 from burnus at gcc dot gnu dot org 2010-05-02 14:32 --- (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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-03-28 15:46:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
--- Comment #10 from dfranke at gcc dot gnu dot org 2009-01-03 23:26 --- (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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
--- Comment #7 from burnus at gcc dot gnu dot org 2008-12-08 11:33 --- (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.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
--- Comment #8 from dfranke at gcc dot gnu dot org 2008-12-08 12:50 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
--- Comment #9 from mikael at gcc dot gnu dot org 2008-12-08 14:25 --- (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. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
--- Comment #6 from dfranke at gcc dot gnu dot org 2008-12-07 19:38 --- 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? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
--- Comment #5 from dfranke at gcc dot gnu dot org 2008-08-18 20:56 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2008-05-14 10:48 --- (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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
--- Comment #3 from jkrahn at nc dot rr dot com 2008-05-08 18:19 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
--- Comment #2 from dfranke at gcc dot gnu dot org 2008-04-06 00:20 --- Related: PR35055 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707
[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-03-28 23:19 --- 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. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707
