[Bug fortran/94931] New: request: print include path

[Bug fortran/94931] New: request: print include path

[ryofurue at gmail dot com]

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

            Bug ID: 94931
           Summary: request: print include path
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ryofurue at gmail dot com
  Target Milestone: ---

I'm not familiar with this bug tracker. I mean to submit a request, not a bug
report.
----
Sorry if I missed anything, but it seems to me that there is no (official) way
to print the list of paths which gfortran searches for include files. If that
is correct, my request would be to provide a means to print the paths.

The `--print-search-dirs` option indicates paths only for the installation,
executables, and libraries (It seems to me).

This discussion applies to the INCLUDE statement of the Fortran language, not
the `#include` directive of the preprocessor.

Off-topic: I wonder if there is a discussion available online about why
/usr/include or something like that is not searched by default? Is there a
common (more or less standard) place for gfortran to search?

[Bug fortran/94931] request: print include path

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Ryo Furue from comment #0)
> I'm not familiar with this bug tracker. I mean to submit a request, not a
> bug report.
> ----
> Sorry if I missed anything, but it seems to me that there is no (official)
> way to print the list of paths which gfortran searches for include files. If
> that is correct, my request would be to provide a means to print the paths.
> 
> The `--print-search-dirs` option indicates paths only for the installation,
> executables, and libraries (It seems to me).
> 
> This discussion applies to the INCLUDE statement of the Fortran language,
> not the `#include` directive of the preprocessor.
> 
> Off-topic: I wonder if there is a discussion available online about why
> /usr/include or something like that is not searched by default? Is there a
> common (more or less standard) place for gfortran to search?

There isn't a list of paths.  With the Fortran INCLUDE statement,
by default gfortran looks in the current working directory.  That
is it.  If you have files, which are INCLUDEd, into your program 
is different directories, you can create a list of paths with the
-I option.

gfortran also searches for its own INCLUDE files and intrinsic
modules in a directory created during installation of the compiler.
You can find the name of that directory by using the -v option
during compilation.  For example, on my OS, this command

% gfcx -v -o z a.f90 | & grep -- -fin

yields

-fintrinsic-modules-path
/usr/home/kargl/work/lib/gcc/i586-unknown-freebsd13.0/10.0.0/finclude

It seems to me that an option to print the INCLUDE search
path is not needed. The PR can probably be closed as
RESOLVED WONTFIX, but I'll someone else make that decision.

[Bug fortran/94931] request: print include path

[ryofurue at gmail dot com]

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

--- Comment #2 from Ryo Furue <ryofurue at gmail dot com> ---
Thanks for the detailed description.


> % gfcx -v -o z a.f90 | & grep -- -fin
> 
> yields
> 
> -fintrinsic-modules-path
> /usr/home/kargl/work/lib/gcc/i586-unknown-freebsd13.0/10.0.0/finclude

So, I wonder if it is possible and would make sense to include that information
in the output of  `--print-search-dirs`  ?

[Bug fortran/94931] request: print include path

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Mon, May 04, 2020 at 01:13:22AM +0000, ryofurue at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94931
> 
> --- Comment #2 from Ryo Furue <ryofurue at gmail dot com> ---
> Thanks for the detailed description.
> 
> 
> > % gfcx -v -o z a.f90 | & grep -- -fin
> > 
> > yields
> > 
> > -fintrinsic-modules-path
> > /usr/home/kargl/work/lib/gcc/i586-unknown-freebsd13.0/10.0.0/finclude
> 
> So, I wonder if it is possible and would make sense to include
> that information in the output of  `--print-search-dirs`  ?
> 

Why?  --print-search-dirs does not include information about
C/C++ include paths.  The documentation states

'-print-search-dirs'
     Print the name of the configured installation directory and a list
     of program and library directories 'gcc' searches--and don't do
     anything else.

There is only place gfortran will search for files that
it installs for intrinsic modules, openmp files, and 
openacc files.  There are no user files here.

[Bug fortran/94931] request: print include path

[ryofurue at gmail dot com]

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

--- Comment #4 from Ryo Furue <ryofurue at gmail dot com> ---
> There is only place gfortran will search for files that
> it installs for intrinsic modules, openmp files, and 
> openacc files.  There are no user files here.

I see your point!

So, should a library developer install the include files there (the directory
where the intrinsic modules go)? I suppose that is the design?

Thanks for your patience!

[Bug fortran/94931] request: print include path

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #5 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Mon, May 04, 2020 at 01:33:43AM +0000, ryofurue at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94931
> 
> --- Comment #4 from Ryo Furue <ryofurue at gmail dot com> ---
> > There is only place gfortran will search for files that
> > it installs for intrinsic modules, openmp files, and 
> > openacc files.  There are no user files here.
> 
> I see your point!
> 
> So, should a library developer install the include files there (the directory
> where the intrinsic modules go)? I suppose that is the design?
> 
> Thanks for your patience!
> 

For my personal, projects I put libraries in ${HOME}/lib
and modules in ${HOME}/modules.  I don't use include files
above the library levels.  For a software developer, I
would put the libraries in ${INSTALLDIR}/lib and modules
in ${INSTALLDIR?/modules.  INSTALLDIR could be /usr/local,
and, of course, you would describe this in the user and
installation manuals.

[Bug fortran/94931] request: print include path

[ryofurue at gmail dot com]

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

--- Comment #6 from Ryo Furue <ryofurue at gmail dot com> ---
Thanks again for your comments!

> For a software developer, I
> would put the libraries in ${INSTALLDIR}/lib and modules
> in ${INSTALLDIR?/modules.  INSTALLDIR could be /usr/local,
> and, of course, you would describe this in the user and
> installation manuals.

I see.  So, the directory gfortran searches by default is not intended for
non-gfortran libraries.

I'm definitely drifting off-topic, but my question/request stemmed from the
fact that I initially didn't know why 

    gfortran mysourcefile.f -lnetcdff -netcdff

didn't find /usr/include/netcdf.inc . I thought somethig was wrong.  In
hindsight, it's because gfortran doesn't search /usr/include/ .  So, eventually
I learned that

    gfortran -I/usr/include mysourcefile.f -lnetcdff -lnetcdf

is the answer.

But, then the question is, why don't you need the -L option? as in

    gfortran -I/usr/include mysourcefile.f -L/usr/lib -lnetcdff -netcdf


Why is this asymmetry?  It seems that there are "standard" places to place
libraries but not include files . . . 

I'm not blaming gfortran at all. I'm just wondering what I should say to the
packager of the netCDF library (or what I should do, if I were to package this
library).


Returning to the original issue: Although I led you in the wrong direction
(--print-search-dir, and I'm sorry about that), my original request may not be
invalid: I think it would be nice if the answer(*) is available somewhere,
either in the form of an output from a command line option or in the official
document or somewhere.


(*) the answer to the question: where does gfortran search for include files by
default?  (Answer: the current directory and an internal directory where
gfortran's internal modules are stored.)

[Bug fortran/94931] request: print include path

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Mon, May 04, 2020 at 08:23:17AM +0000, ryofurue at gmail dot com wrote:
> 
> But, then the question is, why don't you need the -L option? as in
> 
>     gfortran -I/usr/include mysourcefile.f -L/usr/lib -lnetcdff -netcdf
> 
> 
> Why is this asymmetry?  It seems that there are "standard" places to place
> libraries but not include files . . . 

I think you're seeing the effects of shared libraries.  The
loader has library information:

%  ldconfig -r | grep netcdf
        453:-lnetcdf.15 => /usr/local/lib/libnetcdf.so.15

My advice is to always have the correct -L options.

[Bug fortran/94931] request: print include path

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
           Severity|normal                      |enhancement
   Last reconfirmed|                            |2020-07-20
             Status|UNCONFIRMED                 |WAITING
           Priority|P3                          |P5

--- Comment #8 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
WONTFIX?