Do not define project(CBMC ...) twice to fix CMake failures #8435
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
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #8435 +/- ##
========================================
Coverage 78.34% 78.34%
========================================
Files 1726 1726
Lines 188769 188769
Branches 18503 18503
========================================
Hits 147891 147891
Misses 40878 40878 ☔ View full report in Codecov by Sentry. |
tautschnig
changed the title
`project(P, ...)` sets the CMake variablee `P_SOURCE_DIR` to whichever directory that CMake file is in. We happen to rely on the value of `CBMC_SOURCE_DIR` in several places. Invoking `project(P, ...)` twice in different directories for the same value of `P` will cause hard-to-reproduce behaviour. Even though this duplication was in place ever since, 7949cac, we apparently got lucky until a few days ago. Now, however, we see sporadic failures on GitHub runners, such as https://github.com/diffblue/cbmc/actions/runs/10677152028/job/29591809621. GitHub's runner image notes do not point out any recent change to CMake, but it might as well be changes to the kernel's scheduler.
tautschnig
force-pushed
the
debug-cmake-fail
branch
from
e14c2eb to
aeeb39f
Compare
3 tasks
TGWDB
approved these changes
Sep 5, 2024
There was a problem hiding this comment.
Approving as a suitable fix for now. Reading it there seems to be some tension between CBMC_SOURCE_DIR and SRC neither of which are where the source code lives. Maybe disambiguating with CBMC_ROOT_DIR might be clearer... but this is an improvement and not necessary for now.
tautschnig
added a commit
to tautschnig/cbmc
that referenced
this pull request
Sep 19, 2024
This release addresses build failures on aarch64 (64-bit ARM) platforms (via PR diffblue#8366) and for some CMake configurations (via PR diffblue#8435). Users of loop invariants with dynamic frames have two changes to their user experience: 1) Users will no longer need to give unwinding specifications for `do { ... } while(0)` loops. 2) Loop invariants that are conjunctions will be turned into more fine-grained properties to ease debugging of loop invariants when they aren't successfully proved.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
project(P, ...)sets the CMake variableeP_SOURCE_DIRto whicheverdirectory that CMake file is in. We happen to rely on the value of
CBMC_SOURCE_DIRin several places. Invokingproject(P, ...)twicein different directories for the same value of
Pwill causehard-to-reproduce behaviour. Even though this duplication was in place
ever since, 7949cac, we apparently got lucky until a few days ago.
Now, however, we see sporadic failures on GitHub runners, such as
https://github.com/diffblue/cbmc/actions/runs/10677152028/job/29591809621.
GitHub's runner image notes do not point out any recent change to CMake,
but it might as well be changes to the kernel's scheduler.