Description
SCons scanners often emit a DependencyWarning if an "include file" detected during scanning is not found. This usage should, at least in some cases, be in some sort of "informational" category, rather than "warning". The C/C++ scanner, for example, wants to follow the policy that system headers (<stdio.h>, etc.) not be tracked as implicit dependencies. It implements that by searching for a scanned include using the paths in CPPPATHS. Any includes scanned from files which are not found are added to the scanner object's missing attribute, which is later used to issue DependencyWarning. Not-found files just aren't added as deps, which is how the system-header thing works - this isn't exactly right, but it works fine: when you actually compile, any missing headers will cause a compilation error anyway, as you expect, so it's not our job to fail the build because they're missing. However, a warning is something that's potentially a problem, and for the system headers, it's not a problem.
We just had a Discord discussion with a developer who wanted to have warnings cause failures, which is a moderately common thing for people to do when being strict about their programming environment. That caused the build to abort, even though the failure to find stdio.h in CPPPATHS is not indicative of a problem at all:
SCons.Warnings.warningAsException(True)
SetOption('warn', 'all')If we're going to consider that to be valid usage, then the system headers problem needs a different solution, or perhaps more simply, it shouldn't be a warning. I understand the desire to be able to let you know about things which were scanned as potential dependencies, but which were not actually added as dependencies - that's a useful debugging tool for non-system headers. We don't know something is a system header, we're just triggering off not-found and assuming it's probably a system header. Perhaps another approach would be to present missing-deps under a --debug option rather than through a warning?