`AllowSubstExceptions` may clash with some predefined macros

[mwichmann]

This issue comes from the mailing list thread at https://pairlist4.pair.net/pipermail/scons-users/2024-April/009346.html

Some of the default values of macro-like construction variables depend on the behavior that, when substituted, a token representing a variable not defined in the construction environment is replaced with an empty string. This is used to provide conditional inclusion in a relatively concise manner. However, this empty-string token replacement is itself conditional: it only takes place if the exception raised when accessing an undefined variable is one listed in the AllowableExceptions list in the Subst module. That list is settable via the public API AllowSubstExceptions. If the list is cleared, so the user can detect the usage of undefined variables in the build, then an exception is raised instead, and this can break things. The substitution methods try to do the right thing here, but there is an extra factor: sometimes there's a callable object involved, and those need to respect the rules too.

It is possible - investigation pending - that the scope of the problem is limited to the case outlined in the mailing list thread: the two functions __libversionflags and __lib_either_version_flag, which return None rather than an empty string. At a brief glance, no other function in the SCons core used in this kind of variable expansion can return None. I don't see where we say anywhere that "don't return None" is a requirement, but it's worth checking whether that should be a rule, and these two functions fixed to return empty string. Again... some more digging required.

[mwichmann]

Adding the documentation tag, maybe we should say something about the rules involved, though it's not clear what form such a doc addition would take yet.