Dependency checking in f90 doesn't work with module subdirs

[bdbaddog]

This issue was originally created at: 2008-04-23 06:14:56.
This issue was reported by: warer.

warer said at 2008-04-23 06:14:57

I am having problems compiling two fortran files. The dependency checking in scons does not detect that main.f90 depends on calculator.f90. So it tries to compile main.f90 first, which dosen't work.

SConstruct:

import os
 
env = Environment(ENV = os.environ,tools = ['default','ifort'])
 
f90_common = ['src/calculator.f90']
f90_main  = ['src/main.f90']
o_f90_common = env.Object(f90_common)
 
#f90_common.extend(f90_main)
#f90_main = f90_common
f90_main.extend(f90_common)
 
env.Program('app',f90_main)

As you can see if i uncomment the two lines, things will work. Because then it compiles in the correct order. Running with -j flag also fails because it tries to compile bouth at the same time.

Calculator.f90:

module calculator
  implicit none
contains
  subroutine add (a, b, output)
    integer, intent (in) :: a, b
    integer, intent (out) :: output
    output = a + b
  end subroutine add
end module calculator

main.f90:

PROGRAM Test
    use calculator, only: add
    integer:: result
 
    call add (2,2,result)
END PROGRAM  Test

warer said at 2008-04-23 06:15:57

Created an attachment (id=375)

sconstructfile

warer said at 2008-04-23 06:16:21

Created an attachment (id=376)

calculator

warer said at 2008-04-23 06:16:34

Created an attachment (id=377)

main file

stevenknight said at 2008-04-23 06:31:52

Reassigning to David for investigation.

Truls: is this something that worked in earlier versions of SCons and is now broken in 0.98.1, or are you trying 0.98.1 for the first time?

cournape said at 2008-04-23 06:43:28

I can't reproduce this problem on my machine with 0.98.2 (I tried comment/uncommenting, build several times, invert the list order at random).

gregnoel said at 2008-04-23 06:56:49

What happens if you do this?

    Requires('main.o', 'calculator.o')

That should always cause it to build calculator.o before main.o.

warer said at 2008-04-23 07:11:43

This was also broken in 0.97 release. I can also check in 0.98.2 but according to the changelog nothing like this is changed.

stevenknight said at 2008-04-23 18:19:18

Truls--

Can you double-check scons --version on the version that's still showing the problem, to make sure it's reporting that the underlying build engine (the SCons library) is 0.98.1? Some people have had installation problems where the wrapping script is 0.98.1, but that script still finds and uses the previously-installed version of the library (0.97 or whatever).

Thanks,

    --SK

cournape said at 2008-04-23 20:22:09

Ok, forget my previous comment, I can reproduce the problem (I got someone complaining about the same kind of problem, and I could reproduce his problem every time).

The problem is not dependency scanning per se, but the fact that the sources are in a subdirectory. If you put the source files in the same directory as the scons script, everything works as expected:

1: everythin in the same directory:

+-.
  +-app
  | +-main.o
  | | +-calculator.mod
  | +-calculator.o
  +-calculator.mod
  +-calculator.o
  +-main.o
    +-calculator.mod

2: as mentioned in the bug report:

+-.
  +-app
  | +-src/main.o
  | +-src/calculator.o
  +-calculator.mod
  +-src

In the scons manual, for FORTRANPATH, it is said:

"The list of directories that the Fortran compiler will search for include files and (for some compilers) module files. The Fortran implicit dependency scanner will search these directories for include files (but not module files since they are autogenerated and, as such, may not actually exist at the time the scan takes place)."

So here is the problem: how do you set a directory where to look for modules in scons ?

stevenknight said at 2008-04-23 23:22:07

Hi David--

It looks to me like that documentation in the man page might be out of date. At first glance, the code in Scanner/Fortran.py seems to run both the modules and includes that it finds through the find_includes() method that's responsible for searching the path. Certainly accomodating generated header files is well within SCons' abilities, so I don't see why generated modules should be any more difficult.

(I might be mistaken, though; that text seems to date from the same change that added the code.)

If I'm mistaken and it really doesn't find modules already, then we should add whatever interface makes sense to support the functionality. If it makes sense for $FORTRANPATH to be the one true path for searching both include files and modules, great, that's one less variable to worry about. If there are real-world use cases that suggest people might need separate paths for include files vs. module, then maybe we need to add something like a $FORTRANMODPATH. But I'll defer to your>judgment on what makes the most sense for Fortran users.

Comments?

    --SK

cournape said at 2008-04-23 23:51:36

Ok, from what you say, it should not be too difficult to fix, but a decision needs to be made on which cvar does what. There is FORTRANPATH, and FORTRANMODDIR* variables.

According to man gfortran, the Idir option " is also used to search for .mod files when previously compiled modules are required by a "USE" statement.". There is also the -M/-J option, which is the flag for FORTRANMODDIRPREFIX. According to gfortran documentation, any path in -M/-J is also appended to the list of path looked for modules. man ifort seems to say that ifort has the same conventions.

So if I understand correctly, fortran scanner should look in the concatenated list of FORTRANPATH + FORTRANMODDIR, no ?

cournape said at 2008-04-23 23:59:41

Actually, it makes more sense to have one third variable, and to redefine FORTRANPATH, but it may not be 100% backward compatible:

• one cvar to say where to look for header (-I of gfortran, for example)
• one cvar to say where to put mod (-J/-M of gfortran)
• one cvar to say where to look for mod, and which would, in the cases of gfortran and ifort (and maybe other), be a concatenation of the first two, but not necessarily.

We would also need to set FORTRANMODPREFIX flags in the tools (which is trivial).

stevenknight said at 2008-05-22 09:52:39

Target milestone per bug party triage. David to set Priority according to his judgment and available time.

gregnoel said at 2008-12-26 13:29:13

Adjust triage of issues.

warer attached SConstruct at 2008-04-23 06:15:57.

sconstructfile

warer attached calculator.f90 at 2008-04-23 06:16:21.

calculator

warer attached main.f90 at 2008-04-23 06:16:34.

main file