Re: Running Python from the source repo
On Tue, Aug 9, 2016 at 2:55 AM, Terry Reedy wrote: > This works great. Might there be any way to collect together > the warning messages? There were perhaps 100 for the changes in > the last few weeks. (People on non-windows seems to routinely write code > that msc does not like.) Glad it works! Collecting warning messages is less simple, you'd probably get the best results from writing a Python script to drive the build.bats and do what you want with the output. You can also pass '-v' to build.bat to get more verbose output, which includes a summary of warnings and errors at the end of each build. -- Zach -- https://mail.python.org/mailman/listinfo/python-list
Re: Running Python from the source repo
On 8/8/2016 5:25 PM, Random832 wrote: On Mon, Aug 8, 2016, at 15:25, Terry Reedy wrote: Last January, I wrote a batch file to build all three versions with the 'optional' extensions. I started rebuilding more often after this. 36\pcbuild\build.bat -e -d 35\pcbuild\build.bat -e -d 27\pcbuild\build.bat -e -d Thanks for making this possible. It initially worked, but now it stops after the first command, even without errors. Has a flag been changed to treat warnings as errors? How can I change the .bat to wrap each command with the equivalent of try: except: pass? I'm not sure how it ever worked, but you have to use "call" to run one batch file from another batch file, otherwise it doesn't start a recursive command interpreter and so it won't run anything else in the outer batch file. Perhaps I mis-remember. Zack's revision using call works. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Running Python from the source repo
On 8/8/2016 5:16 PM, Zachary Ware wrote: On Mon, Aug 8, 2016 at 2:25 PM, Terry Reedy wrote: Last January, I wrote a batch file to build all three versions with the 'optional' extensions. I started rebuilding more often after this. 36\pcbuild\build.bat -e -d 35\pcbuild\build.bat -e -d 27\pcbuild\build.bat -e -d Thanks for making this possible. It initially worked, but now it stops after the first command, even without errors. Has a flag been changed to treat warnings as errors? How can I change the .bat to wrap each command with the equivalent of try: except: pass? I'm not sure why that would have stopped working, but the way to use a .bat from a .bat is to 'call' it: call 36\PCbuild\build.bat -e -d .bat scripts don't care about the exit codes of what they run, errors must be explicitly checked and 'exit' called if you want the script to die early. Try this for an unconditional build on all three branches, with a report at the end if any of them failed: call 36\PCbuild\build.bat -e -d set rc36=%ERRORLEVEL% call 35\PCbuild\build.bat -e -d set rc35=%ERRORLEVEL% call 27\PCbuild\build.bat -e -d set rc27=%ERRORLEVEL% @if %rc36% NEQ 0 ( echo 3.6 build failed, rc: %rc36% ) @if %rc35% NEQ 0 ( echo 3.5 build failed, rc: %rc35% ) @if %rc27% NEQ 0 ( echo 2.7 build failed, rc: %rc27% ) This works great. Might there be any way to collect together the warning messages? There were perhaps 100 for the changes in the last few weeks. (People on non-windows seems to routinely write code that msc does not like.) -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Running Python from the source repo
On Mon, Aug 8, 2016, at 15:25, Terry Reedy wrote: > Last January, I wrote a batch file to build all three versions with the > 'optional' extensions. I started rebuilding more often after this. > > 36\pcbuild\build.bat -e -d > 35\pcbuild\build.bat -e -d > 27\pcbuild\build.bat -e -d > > Thanks for making this possible. It initially worked, but now it stops > after the first command, even without errors. Has a flag been changed > to treat warnings as errors? How can I change the .bat to wrap each > command with the equivalent of try: except: pass? I'm not sure how it ever worked, but you have to use "call" to run one batch file from another batch file, otherwise it doesn't start a recursive command interpreter and so it won't run anything else in the outer batch file. I don't know if .cmd files have this limitation. -- https://mail.python.org/mailman/listinfo/python-list
Re: Running Python from the source repo
On Mon, Aug 8, 2016 at 2:25 PM, Terry Reedy wrote: > Last January, I wrote a batch file to build all three versions with the > 'optional' extensions. I started rebuilding more often after this. > > 36\pcbuild\build.bat -e -d > 35\pcbuild\build.bat -e -d > 27\pcbuild\build.bat -e -d > > Thanks for making this possible. It initially worked, but now it stops > after the first command, even without errors. Has a flag been changed to > treat warnings as errors? How can I change the .bat to wrap each command > with the equivalent of try: except: pass? I'm not sure why that would have stopped working, but the way to use a .bat from a .bat is to 'call' it: call 36\PCbuild\build.bat -e -d .bat scripts don't care about the exit codes of what they run, errors must be explicitly checked and 'exit' called if you want the script to die early. Try this for an unconditional build on all three branches, with a report at the end if any of them failed: call 36\PCbuild\build.bat -e -d set rc36=%ERRORLEVEL% call 35\PCbuild\build.bat -e -d set rc35=%ERRORLEVEL% call 27\PCbuild\build.bat -e -d set rc27=%ERRORLEVEL% @if %rc36% NEQ 0 ( echo 3.6 build failed, rc: %rc36% ) @if %rc35% NEQ 0 ( echo 3.5 build failed, rc: %rc35% ) @if %rc27% NEQ 0 ( echo 2.7 build failed, rc: %rc27% ) -- Zach -- https://mail.python.org/mailman/listinfo/python-list
Re: Running Python from the source repo
On 8/8/2016 12:24 PM, Zachary Ware wrote: I generally assume that if I'm testing a patch, I'm going to need to rebuild regardless of what the patch actually touches. I often wait until the patch is applied before I do the rebuild, or if I'm manually testing a bug I go ahead and do the rebuild immediately. Most make targets (including 'test') will go ahead make sure the build is up to date without your input. Usually the slowest part of a rebuild is rerunning ./configure, which 'make' will do for you if it determines that it should. You can speed up ./configure by passing it the '--config-cache' (or '-C') option. If you're on a multi-core machine, also remember to pass '-j' to make to speed up building, and also to regrtest (which you can do with 'make test TESTOPTS=-j9') to speed up testing. [1]https://www.mercurial-scm.org/wiki/FetchExtension Last January, I wrote a batch file to build all three versions with the 'optional' extensions. I started rebuilding more often after this. 36\pcbuild\build.bat -e -d 35\pcbuild\build.bat -e -d 27\pcbuild\build.bat -e -d Thanks for making this possible. It initially worked, but now it stops after the first command, even without errors. Has a flag been changed to treat warnings as errors? How can I change the .bat to wrap each command with the equivalent of try: except: pass? -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Running Python from the source repo
On Sun, Aug 7, 2016 at 9:11 PM, Steven D'Aprano wrote: > I have cloned the Python source repo, and build CPython, as described here: > > https://docs.python.org/devguide/ > > > Now a little bit later, I want to update the repo, so I run: > > hg fetch According to the hg docs [1], you should probably avoid 'hg fetch'. Use 'hg pull -u' (or 'hg pull && hg update') instead. > to get and apply any changes. How do I know if I need to rebuild Python? I > don't want to have to rebuild after every fetch, because that's quite time > consuming (I estimate about five minutes on my machine, just long enough to > be a distraction but not long enough to get into something else). Plus the > time to run the tests (significantly longer). > > What do others do? I generally assume that if I'm testing a patch, I'm going to need to rebuild regardless of what the patch actually touches. I often wait until the patch is applied before I do the rebuild, or if I'm manually testing a bug I go ahead and do the rebuild immediately. Most make targets (including 'test') will go ahead make sure the build is up to date without your input. Usually the slowest part of a rebuild is rerunning ./configure, which 'make' will do for you if it determines that it should. You can speed up ./configure by passing it the '--config-cache' (or '-C') option. If you're on a multi-core machine, also remember to pass '-j' to make to speed up building, and also to regrtest (which you can do with 'make test TESTOPTS=-j9') to speed up testing. [1]https://www.mercurial-scm.org/wiki/FetchExtension -- Zach -- https://mail.python.org/mailman/listinfo/python-list
Re: Running Python from the source repo
On Mon, Aug 8, 2016 at 12:11 PM, Steven D'Aprano wrote: > I have cloned the Python source repo, and build CPython, as described here: > > https://docs.python.org/devguide/ > > > Now a little bit later, I want to update the repo, so I run: > > hg fetch > > to get and apply any changes. How do I know if I need to rebuild Python? I > don't want to have to rebuild after every fetch, because that's quite time > consuming (I estimate about five minutes on my machine, just long enough to > be a distraction but not long enough to get into something else). Plus the > time to run the tests (significantly longer). > > What do others do? I use 'hg pull -u' - that's the same as 'hg fetch' right? After that, I just 'make'. It won't rebuild everything, only what's changed. If you 'make' and immediately 'make' again, it's pretty quick - at least, it is on my Linux box, where it's cheap to 'stat' a bunch of files to see if they've changed. On other systems, it might be a bit slower, but it certainly won't take as long as a full build from scratch. The only time a full rebuild is needed is if something really fundamental has changed. I just pulled now, and the first build took 1m39s, which involved a reconfigure and a good bit of chugging; then a rebuild looked like this: rosuav@sikorsky:~/cpython$ time make running build running build_ext running build_scripts copying and adjusting /home/rosuav/cpython/Tools/scripts/pydoc3 -> build/scripts-3.6 copying and adjusting /home/rosuav/cpython/Tools/scripts/idle3 -> build/scripts-3.6 copying and adjusting /home/rosuav/cpython/Tools/scripts/2to3 -> build/scripts-3.6 copying and adjusting /home/rosuav/cpython/Tools/scripts/pyvenv -> build/scripts-3.6 changing mode of build/scripts-3.6/pydoc3 from 644 to 755 changing mode of build/scripts-3.6/idle3 from 644 to 755 changing mode of build/scripts-3.6/2to3 from 644 to 755 changing mode of build/scripts-3.6/pyvenv from 644 to 755 renaming build/scripts-3.6/pydoc3 to build/scripts-3.6/pydoc3.6 renaming build/scripts-3.6/idle3 to build/scripts-3.6/idle3.6 renaming build/scripts-3.6/2to3 to build/scripts-3.6/2to3-3.6 renaming build/scripts-3.6/pyvenv to build/scripts-3.6/pyvenv-3.6 real 0m0.148s user 0m0.108s sys 0m0.028s rosuav@sikorsky:~/cpython$ So normally just run 'make' and let it do its work. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
