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.
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.Beta Was this translation helpful? Give feedback.
All reactions