Implicit targets that affect the build

[mwichmann]

There is a category of target files that fall outside the usual SCons declaration process - files not explicitly specified as targets in a Builder call. There are roughly speaking three types:

1. Implicitly Declared Targets:

   • Some targets don't need explicit listing because they can be inferred.
   • Single-source builders, such as Object, determine the target implicitly for each source file if given a list.
   • Other builders, when given only a single source file, can determine the target.
   • These targets contribute to the link step, and their nodes integrate fine into the dependency graph.

2. Build By-Products

   • These are files generated during the build of a declared target, but not directly used in the overall build process.
   • Examples include compilation databases and Windows program database (PDB) files.
   • PDB files, for instance, contain information for external tools (like debuggers) but do not impact the compilation process itself.
   • If a single file in this category can be contributed to by multiple builds, as for PDB, SCons may internally use the SideEffect mechanism to ensure that multiple object builds don't interfere with each other.
   • These targets cause no problems in the dependency graph, as they don't have any must-build relationships.

3. By-Products with Special Considerations:

   • These are generated files that are necessary during the build but don't directly affect the final link.
   • Examples include pre-compiled headers, Fortran module files, and D Interface files. Once implemented, will also include C++ module files.
   • For instance, Fortran module files, generated when compiling a source file containing a MODULE declaration, are crucial dependencies for other source files which declare they USE the module.
   • However, these module files are not object files and should not be part of the link step (for gfortran, passing them to a link step results in an error), so if a module file is added to the target list by an emitter, it may need to be filtered out before that list is passed to a subsequent Program call.
   • Such targets do need to go in the dependency graph because there are must-build relationships: if the module file has not been generated before a source file that uses it is compiled, the build fails.

It's handling the third type that I'd like to resolve with this Discussion.

1. Variant Directories and File Placement:
   • The challenge arises when determining where these files should reside.
   • For example, gfortran defaults to placing module files in the directory where the compiler is invoked (for SCons, usually the project top directory).
   • However, when using a variant directory, the files should go into the variant directory both for proper source/build isolation, and because different variants might cause different module file contents to be generated.
   • A module file could already exist elsewhere (e.g., in a Repository) and, if so, should be found for use - but not for regeneration.
   • Compiler arguments can specify a different output directory, but that implies scanners must compute the correct path and ensure it appears in the Node tree to establish proper dependencies. It also needs to be conveyed to the rest of the build: usually the compiler needs to be told where to find the module file when building sources that depend on it.