Fix C coverage #20222
Merged
Fix C coverage #20222
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When C coverage is enabled, the path to the object file is saved. Since we re-use source files in multiple extensions, libgcov will complain at runtime that it is trying to save coverage for the same object file at different timestamps (since each source is compiled again for each extension). Thus, we need to use unique temporary build directories to store object files for each extension.
|
Hmm, I guess |
tacaswell
approved these changes
May 14, 2021
jklymak
approved these changes
May 14, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
PR Summary
This was noticed while attempting Ubuntu 20.04 builds, but actually affects any system with new gcc. I was able to reproduce on Fedora by setting
CPPFLAGS=--coverage.The problem is that gcc will save the object file name and the time it was created, and warn about producing coverage if those differ. This is the case for our extensions, because we share some source files between them, and setuptools builds object files in the same directory.
The fix is simply to override the temporary directory while building a single extension to some path that is unique.
Additionally, when generating coverage, we need to tell gcc to save absolute paths (for CI.)You can test this by compiling with
CPPFLAGS=--coveragein the environment, and then running anything. It will produce warnings from libgcov. This occurs in tests, but onlytest_sphinxextfails, because it captures stderr from a subprocess and treats it as an error.PR Checklist
pytestpasses).flake8on changed files to check).flake8-docstringsand runflake8 --docstring-convention=all).doc/users/next_whats_new/(follow instructions in README.rst there).doc/api/next_api_changes/(follow instructions in README.rst there).