BUG in compiler ?

[WSinc]

There is a problem with INCLUDE files.

You can open the include file from a subroutine, but when that same include file is mentioned in the MAIN

 program, it generates an error message.

It might have to do with the MAIN program being somewhere else in in file hierarchy.

So you need a special trick to open the INCLUDE file  ? ?

EXAMPLE:

program test01

include "remark.txt"

end

subroutine sub01

include "remark.txt"

end

In the above example, if sub01 can include that file, then the MAIN program cannot find it -

Is this already known about ?

[IanH]

Please provide more detail.

Here is my attempt at reproducing your example, making assumptions about the details that you have not provided.  I don't get an error.

>dir
...
2017-10-14  06:16    <DIR>          .
2017-10-14  06:15    <DIR>          ..
2017-10-14  06:15                27 remark.txt
2017-10-14  06:15                92 example.f90
...

>type example.f90
program test01
  include 'remark.txt'
end
subroutine sub01
  include 'remark.txt'
end

>type remark.txt
! This just has a remark.

>ifort example.f90
Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 18.0.0.124 Build 20170811
Copyright (C) 1985-2017 Intel Corporation.  All rights reserved.

Microsoft (R) Incremental Linker Version 14.00.24215.1
Copyright (C) Microsoft Corporation.  All rights reserved.

-out:example.exe
-subsystem:console
example.obj

[Steve_Lionel]

It would also help if you said what the error was (show the exact and complete text of the error.)

Note that the default folder for INCLUDE is the one for the source file that has the INCLUDE statement.

[WSinc]

Well, as Steve pointed out, the main program is in a different directory than the included file.

That's possibly why I get the error ?

Ian did not try to compile the main program, at least I dont see that in his example.

I was wondering if there is a way to force all the object files to be in the same directory location ?

Or change the INCLUDE in the MAIN program to point to the correct directory location ?

I was trying to spare you guys from having to wade thru a really complicated example.

[Steve_Lionel]

So if the main program source file is in one directory, and the include file is in another, how do you expect the compiler to find it?

You can use "Additional include directories" (/INCLUDE) to specify additional places to look for include files. As I wrote, the default is that it looks in the same folder as the source with the INCLUDE statement.

[WSinc]

Well, I had trouble putting all the same source codes in one directory.  It does not give us an easy choice,

at least one that I know about.

Thats what leads to this problem.

Maybe I should have just MODULES instead, and use USE instead of Include ?

That's the more modern approach anyway, right ?

[Steve_Lionel]

With modules, at least, the compiler and the Visual Studio integration would make sure that the compiled module was found when you compile. I don't know what you are using include files for. I will note, though, that include files work fine as long as you understand the rules for how they are located. The typical approach is to add the path for the include files to "Additional include directories". Another is to use a relative path in the INCLUDE statement, such as:

INCLUDE '..\includes\myinc.inc'

I'll also note that it's difficult to help you when you don't provide all the details of a problem, leaving us to guess what error you actually saw and what your program really looks like. A meaningless title such as "BUG in compiler ?" doesn't help either. Bill, you've been in this forum for long enough that you should have picked up on what helps us help you.

[andrew_4619]

I gave up with include files when modules became available, as they are much more useful and powerful also. Does VS track dependencies of include files BTW? 

[Steve_Lionel]

Andrew, do you mean does VS look in INCLUDE files for USE statements? I think it does. That's really the only dependence analysis done.

[mecej4]

andrew_4619 wrote:
Does VS track dependencies of include files BTW? 

Specifically, if a source file is left as it was but one of its include files is touched, will the VS build system recompile the source file to build a new .OBJ file? I think that it should, but I don't know if it does.

With Unix make, or nmake, you would have to provide an explicit rule in the makefile to manage such include file dependencies.

[Steve_Lionel]

I am pretty sure that include files are, um, included in the dependency analysis for recompiles.

[andrew_4619]

I made  quick test and yes if the include file is modified outside VS  then vs will rebuild all sources that have that include file. You can't see or step into any code lines in the include file in the debugger.

[FortranFan]

andrew_4619 wrote:

.. You can't see or step into any code lines in the include file in the debugger.

An option is to place a breakpoint prior to the INCLUDE statement; the VS integration then does step into the include file as shown below:

[andrew_4619]

I did that, maybe it is because my include was a .txt and not a recognised for Fortran file type? Was at V18 BTW?

[andrew_4619]

OK it does not work only if the include has the first executable statements for a quick tests,,..

Purely academic as I don't use includes other than for resource declarations/parameters.