Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DependencyWarning is somewhat misused #4461

Open
mwichmann opened this issue Jan 9, 2024 · 1 comment
Open

DependencyWarning is somewhat misused #4461

mwichmann opened this issue Jan 9, 2024 · 1 comment
Labels

Comments

@mwichmann
Copy link
Collaborator

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?

@mwichmann
Copy link
Collaborator Author

mwichmann commented Jan 10, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant