[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files

[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files

[dominiq at lps dot ens.fr]

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

[burnus at gcc dot gnu.org]

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

[dominiq at lps dot ens.fr]

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

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35707

--- Comment #17 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
*** Bug 49138 has been marked as a duplicate of this bug. ***

[Bug fortran/35707] Search /usr/local/include and /usr/include for .mod files

[dominiq at lps dot ens.fr]

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-<version>} 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

[dfranke at gcc dot gnu dot org]

------- 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

[burnus at gcc dot gnu dot org]

------- 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

[dfranke at gcc dot gnu dot org]

------- 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

[fxcoudert at gcc dot gnu dot org]

-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-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

[dfranke at gcc dot gnu dot org]

------- 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

[mikael at gcc dot gnu dot org]

------- 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

[dfranke at gcc dot gnu dot org]

------- 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

[burnus at gcc dot gnu dot org]

------- 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

[dfranke at gcc dot gnu dot org]

------- 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

[dfranke at gcc dot gnu dot org]

------- 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

[fxcoudert at gcc dot gnu dot org]

------- 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

[jkrahn at nc dot rr dot com]

------- 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

[dfranke at gcc dot gnu dot org]

------- 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

[dfranke at gcc dot gnu dot org]

------- 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