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
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:
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?
The text was updated successfully, but these errors were encountered:
Added note: I'd really like to see this intentional exclusion ("it's probably a system header, so it's okay we didn't find it in our limited search") documented, in code comments if nowhere else. I had to guess my way to why the Fortran scanner was excluding deps, and ended up also excluding not-found module files, which are a different category, as they can be generated, and so (probably) should have dependencies generated for them.
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 inCPPPATHS
. Any includes scanned from files which are not found are added to the scanner object'smissing
attribute, which is later used to issueDependencyWarning
. 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
inCPPPATHS
is not indicative of a problem at 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?The text was updated successfully, but these errors were encountered: