You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(sorry the title isn't great - if someone suggests a better one I'll update)
There is a class of undeclared target files which don't perfectly fit the SCons model of targets. What we do have:
files produced during the build of a declared target, but which don't need to participate in the build. We have a mechanism for this if they're shared, such as a PDB file on Windows, produced when compiling, but not needed for the build, rather it contains information to guide the debugger; there's only one pdb file, which can be contributed to by multiple objects so SideEffect tries to make sure those things don't happen in parallel.
targets which do contribute to the rest of the build - like calling Object with a whole list of sources; you haven't declared the target files, but SCons figures them out and the Object call returns them.
What we don't have:
Targets which are by-products of a build, and are needed for a build, but don't contribute to the link. For this we have pre-compiled headers, Fortran module files, D Interface files. Possibly C++ modules will fall in this category, not sure. Taking the Fortran module files: a source file that declares a module within it will cause a .mod file to be generated, along with whatever the source file compiles into, normally an object file. This module file must be available when compiling any source file that declares it "uses" the module, so it's a dependency that needs tracking. But, it is not an object file and does not contribute to the link of a program, and in fact if given to a link will result in an error. The practical impact of this is that if you compile a bunch of Fortran objects (e.g. Object(source=result-of-Glob-in-a-source-directory), and save the return from the Object call, you have to filter out the module files before passing that list to a Program call.
These files (be nice to come up with some sort of name) have a high probability of falling afoul of variant directories. Where does the Fortran module file go? By default (for gfortran anyway), it goes in the directory you call the compiler from, which is pretty certainly the wrong place - source/build isolation provided by variant dirs suggest they need to go into the variant - but also has to account for the file already existing somewhere else (repository case). Fortran, and other compilers, do have arguments to allow a different directory, but that means the scanners have to correctly compute the path and make sure it appears in the Node tree: if not, then they won't look like dependencies and SCons will just ignore making sure the build of the module source file happens before the attempted builds of source files that use the module.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
(sorry the title isn't great - if someone suggests a better one I'll update)
There is a class of undeclared target files which don't perfectly fit the SCons model of targets. What we do have:
SideEffect
tries to make sure those things don't happen in parallel.Object
with a whole list of sources; you haven't declared the target files, but SCons figures them out and theObject
call returns them.What we don't have:
.mod
file to be generated, along with whatever the source file compiles into, normally an object file. This module file must be available when compiling any source file that declares it "uses" the module, so it's a dependency that needs tracking. But, it is not an object file and does not contribute to the link of a program, and in fact if given to a link will result in an error. The practical impact of this is that if you compile a bunch of Fortran objects (e.g.Object(source=result-of-Glob-in-a-source-directory)
, and save the return from theObject
call, you have to filter out the module files before passing that list to aProgram
call.These files (be nice to come up with some sort of name) have a high probability of falling afoul of variant directories. Where does the Fortran module file go? By default (for
gfortran
anyway), it goes in the directory you call the compiler from, which is pretty certainly the wrong place - source/build isolation provided by variant dirs suggest they need to go into the variant - but also has to account for the file already existing somewhere else (repository case). Fortran, and other compilers, do have arguments to allow a different directory, but that means the scanners have to correctly compute the path and make sure it appears in the Node tree: if not, then they won't look like dependencies and SCons will just ignore making sure the build of the module source file happens before the attempted builds of source files that use the module.Beta Was this translation helpful? Give feedback.
All reactions