Core code should not refer to SCons.Script

[bdbaddog]

This issue was originally created at: 2008-09-18 00:15:06. This issue was reported by: gregnoel. gregnoel said at 2008-09-18 00:15:06

There are a handful of Tool modules that refer to functions or variables within SCons.Script. This is bad modularization; in theory, Script is but one of a plethora of front-ends to the SCons core, so no core code should refer to it.

This task is to refactor the code so that no core module refers to anything in SCons.Script. This will probably involve rethinking how the core handles such concepts as ARGUMENTS, options, and the like, and come up with an abstraction that deals with them.

gregnoel said at 2008-09-25 01:25:42

Bug party triage.

stevenknight said at 2009-11-10 18:00:20

stevenknight => issues@scons

[mwichmann]

The current list of files in SCons (that are not unit tests) that import SCons.Script is:

SCons/Taskmaster/Job.py  # for GetOption
SCons/Tool/__init__.py  # for ARGUMENTS
SCons/Tool/docbook/__init__.py  # for Scanner
SCons/Tool/install.py  # for GetOption
SCons/Tool/msvs.py  # magic related to MSVS project files, and call stacks
SCons/Tool/ninja/NinjaState.py  # target fiddling
SCons/Tool/ninja/Utils.py  # AddOption
SCons/Tool/ninja/__init__.py  # GetOption, targets, sanitize_shell_env
SCons/Tool/packaging/__init__.py  # AddOption, GetOption
SCons/Util/__init__.py  # print_time
SCons/Util/stats.py  # targets

Seems like over time the concept of SCons.Script as an independent front-end has kind of leaked away. The SOLID principles still suggest that separation is good, but is this still a goal worth pursuing? If tools can work with arguments and options, and the semi-global variables describing targets, and those are defines in SCons.Script, then true separations seems kind of unlikely. (I'll add that I don't like tools adding options, it seems a messy design, but it is what it is at the moment).