Warum hängt der Erfolg von SCons Build von variant_dir name ab?

Question

Mich langweilt ein solches Verhalten zu Tode. Also in SConstruct Datei haben wir die letzte Zeichenkette wie diese:

import compilers, os

env = Environment(ENV = os.environ, TOOLS = ['default'])

def set_compiler(compiler_name):
    env.Replace(FORTRAN = compiler_name)
    env.Replace(F77 = compiler_name)
    env.Replace(F90 = compiler_name)
    env.Replace(F95 = compiler_name)

def set_flags(flags):
    env.Replace(FORTRANFLAGS = flags)
    env.Replace(F77FLAGS = flags)
    env.Replace(F90FLAGS = flags)
    env.Replace(F95FLAGS = flags)

mod_dir_prefix = {
    "gfortran": "-J ",
    "ifort": "-???",
    "pgfortran": "-module " 
}

flags = {
    ("gfortran", "debug"): "-O0 -g -Wall -Wextra -pedantic -fimplicit-none -fbounds-check -fbacktrace",
    ("gfortran", "release"): "-O3",
    ("pgfortran", "debug"): "-O0 -g -C -traceback",
    ("pgfortran",  "release"): "-O4"
}

if not GetOption('clean'):
    print "\nAvailable Fortran compilers:\n"

    for k, v in compilers.compilers_dict().iteritems():
        print "%10s : %s" % (k, v)

    compiler = raw_input("\nChoose compiler: ")

    set_compiler(compiler)

    debug_or_release = raw_input("\nDebug or release: ")

    set_flags(flags[(compiler, debug_or_release)])

    env.Replace(FORTRANMODDIRPREFIX = mod_dir_prefix[compiler])

    env.Replace(LINK = compiler)
    env.Replace(LINKCOM = "$LINK -o $TARGET $LINKFLAGS $SOURCES $_LIBDIRFLAGS $_LIBFLAGS $_FRAMEWORKPATH $_FRAMEWORKS $FRAMEWORKSFLAGS")
    env.Replace(LINKFLAGS = "")

env.Replace(FORTRANMODDIR = '#Mod')
Export('env')

SConscript('Sources/SConscript', variant_dir='Build', duplicate=0)

compilers.py ist mein eigenes Modul, um einige verfügbare Fortran-Compiler zu finden.

Im Ordner Sources befinden sich einige Fortran-Quelldateien.

Quellen \SConscript

Import('env')
env.Program('app', Glob('*.f90'))

Scons unterstützt Fortran und alles funktioniert einwandfrei.

gfortran -o Temp\kinds.o -c -O3 -JMod Sources\kinds.f90
gfortran -o Temp\math.o -c -O3 -JMod Sources\math.f90
gfortran -o Temp\sorts.o -c -O3 -JMod Sources\sorts.f90
gfortran -o Temp\utils.o -c -O3 -JMod Sources\utils.f90
gfortran -o Temp\main.o -c -O3 -JMod Sources\main.f90
gfortran -o Temp\app.exe Temp\kinds.o Temp\main.o Temp\math.o Temp\sorts.o Temp\utils.o
scons: done building targets.

Nach der Umbenennung von variant_dir name in sagen wir #Bin o #Build erhalten wir eine Fehlermeldung:

gfortran -o Bin\kinds.o -c -O3 -JMod Sources\kinds.f90
gfortran -o Bin\main.o -c -O3 -JMod Sources\main.f90
Sources\main.f90:3.11:

  USE sorts
           1
Fatal Error: Can't open module file 'sorts.mod' for reading at (1): No such file or directory

Natürlich spielt die Reihenfolge der Zusammenstellung eine Rolle. Aber warum hängt es vom variant_dir Namen ab? Scheint ein Fehler zu sein, aber vielleicht mache ich etwas falsch.

P.S. Dieses Verhalten ist nicht abhängig von duplicate variabler Wert.
P.P.S. Getestet mit SCons 2.0.1 auf Windows mit Python 2.7 und Mac OS X mit Python 2.5.1.

Answer 1

Dies ist eine Antwort auf einen alten Thread, aber ich hatte praktisch das gleiche Problem und musste nach einer Lösung suchen.

Erstens ist Ihre Build-Reihenfolge wahrscheinlich falsch, weil der Dependency-Scanner für Fortran nicht richtig funktioniert. Versuchen Sie

scons [your_arguments] -n --tree=all | less

der nichts kompiliert, sondern nur die Befehle anzeigt und am Ende den Abhängigkeits-Baum so ausgibt, wie Scons ihn sieht.

Eine mögliche Lösung:

Versuchen Sie, die Zeile hinzuzufügen (ich habe Ihre Quelle für den Kontext hinzugefügt):

env.Replace(FORTRANMODDIR = '#Mod') env.Replace(FORTRANPATH = '.' ] Export('env')

Soweit ich das verstanden habe, sind Pfade relativ zum "virtuellen" Ort der SConscript-Datei (d.h. dem src-Verzeichnis oder der Variante build Verzeichnis), sollte dies das Verzeichnis, das die Quelldateien enthält, zum Suchpfad des Scanners hinzufügen.

In meiner Version von scons (2.3.0) kann ich die Funktion duplicate=0 Argument, da es automatisch das ursprüngliche Quellverzeichnis in den Modulpfad einfügt, wodurch die Befehlszeile wie folgt aussieht -module build/ -module src/ (ifort) und setzt sich im Wesentlichen über meine Vorliebe hinweg, das Quellverzeichnis nicht zu überladen. Dies könnte allerdings ein Fehler sein.