GeezerVison is showing github.com — Out-of-tree builds are not tested. · Issue #89858 · python/cpython
Out-of-tree builds are not tested. #89858Description
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/gpshead'
closed_at = None
created_at = <Date 2021-11-02.23:29:45.063>
labels = ['build', '3.10', '3.11']
title = 'Out-of-tree builds are not tested.'
updated_at = <Date 2021-12-04.10:08:03.694>
user = 'https://github.com/ericsnowcurrently'
bugs.python.org fields:
activity = <Date 2021-12-04.10:08:03.694>
actor = 'christian.heimes'
assignee = 'gregory.p.smith'
closed = False
closed_date = None
closer = None
components = ['Build']
creation = <Date 2021-11-02.23:29:45.063>
creator = 'eric.snow'
dependencies = []
files = []
hgrepos = []
issue_num = 45695
keywords = ['patch']
message_count = 7.0
messages = ['405568', '405572', '405573', '407591', '407594', '407595', '407652']
nosy_count = 6.0
nosy_names = ['gvanrossum', 'gregory.p.smith', 'christian.heimes', 'eric.snow', 'steve.dower', 'erlendaasland']
pr_nums = ['29904']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue45695'
versions = ['Python 3.10', 'Python 3.11']
Activityericsnowcurrently commented on Nov 2, 2021 Currently we don't test builds done outside the source tree, neither on GitHub nor the buildbots. [1] As a result, such builds get broken occasionally. I've certainly broken then a couple times, inadvertently. It would be helpful if we tested out-of-tree builds on GitHub, or at least on a stable buildbot.
FTR, to do an out-of-tree build locally and test it:
mkdir ../build
cd ../build
../cpython/configure
make
./python -m test
[1] Actually I recently added test.test_tools.test_freeze.TestFreeze.test_freeze_simple_script which happens to do an out-of-tree build incidentally. However, we should be testing out-of-tree builds explicitly. zooba commented on Nov 3, 2021 FTR, I used to run all Windows builds out of tree on Azure Pipelines, but too many tests broke so I reverted it:
|
# Relocate build outputs outside of source directory to make cleaning faster |
|
Write-Host '##vso[task.setvariable variable=Py_IntDir]$(Build.BinariesDirectory)\obj' |
|
# UNDONE: Do not build to a different directory because of broken tests |
|
Write-Host '##vso[task.setvariable variable=Py_OutDir]$(Build.SourcesDirectory)\PCbuild' |
Setting $env:Py_OutDir before building is the easiest way to change it. You can also pass "/p:Py_OutDir=<path>" to build.bat, but you'll run into quoting issues almost immediately. gpshead commented on Nov 3, 2021 I always do out of tree builds _(I find people who build anything in tree to be very weird - it makes a mess)_.
I intend to look into making sure a Linux buildbot runs this way but don't let that stop anyone else from doing so. tiran commented on Dec 3, 2021 Good news: I got a test case for OOT build with read-only sources
Bad news: 15 test cases are failing and testing takes much longer because pyc files are missing.
15 re-run tests:
test__xxsubinterpreters test_ast test_bdb test_capi test_doctest
test_import test_importlib test_interpreters test_pickle
test_pydoc test_runpy test_support test_threading test_trace
test_unicodedata
We have to live with read-only OOT builds and writable tests for now. gpshead commented on Dec 3, 2021 Nice trick with that RO bind mount. tests... yes we do have some writable source tree messes in there to be dealt with. erlend-aasland commented on Dec 3, 2021 FWIW, it is also impossible to build the docs OOT without cluttering the source tree.
$ cd ../build
$ make -C ../cpython.git/Doc venv
$ make -C ../cpython.git/Doc html # <= modifies Doc/build in the source treetiran commented on Dec 4, 2021 kumaraditya303 commented on Apr 28, 2022 Test was added in #29904 so closing. neonene commented on May 31, 2022 gh-78436 mentions that test_embed is actually skipped on OOT. gvanrossum commented on May 31, 2022 Reopening until there is agreement on whether this works as required. Reacted by Erlend E. Aasland
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|