gh-93584: Make all install+tests targets depends on all #93589
Conversation
All install targets use the "all" target as synchronization point to prevent race conditions with PGO builds. PGO builds use recursive make, which can lead to two parallel `./python setup.py build` processes that step on each others toes. "test" targets now correctly compile PGO build in a clean repo.
|
This looks like a good cleanup to me. Perhaps a minor improvement is that we could introduce another name for what all these things depend on, something other than "all". Typically "all" is a dummy target that just builds all typical things. It would be a bit better to be more explicit what these other targets require. Could be something like: Maybe that's over complication. |
|
I could not reproduce the error in #93586 anymore with this |
|
@tiran When is ready for review can you unmark it as a draft? |
|
LGTM I will leave it to you if you want to implement @nascheme's idea |
|
Thanks @tiran for the PR |
|
Sorry @tiran, I had trouble checking out the |
…ythonGH-93589) All install targets use the "all" target as synchronization point to prevent race conditions with PGO builds. PGO builds use recursive make, which can lead to two parallel `./python setup.py build` processes that step on each others toes. "test" targets now correctly compile PGO build in a clean repo. (cherry picked from commit 243ed54) Co-authored-by: Christian Heimes <christian@python.org>
|
GH-93603 is a backport of this pull request to the 3.11 branch. |
) (GH-93603) All install targets use the "all" target as synchronization point to prevent race conditions with PGO builds. PGO builds use recursive make, which can lead to two parallel `./python setup.py build` processes that step on each others toes. "test" targets now correctly compile PGO build in a clean repo. (cherry picked from commit 243ed54) Co-authored-by: Christian Heimes <christian@python.org>
All install targets use the "all" target as synchronization point to
prevent race conditions with PGO builds. PGO builds use recursive make,
which can lead to two parallel
./python setup.py buildprocesses thatstep on each others toes.
"test" targets now correctly compile PGO build in a clean repo.