This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: windows batch files are dependent on cmd current directory
Type: enhancement Stage: resolved
Components: Build, Windows Versions: Python 3.5
Status: closed Resolution: fixed
Dependencies: Superseder: Update Windows build batch scripts
View: 21907
Assigned To: zach.ware Nosy List: brian.curtin, loewis, r.david.murray, ssbarnea, tim.golden, zach.ware
Priority: normal Keywords: patch

Created on 2010-09-10 11:36 by ssbarnea, last changed 2022-04-11 14:57 by admin. This issue is now closed.

File name Uploaded Description Edit
path_for_bug_9822_v1.patch ssbarnea, 2010-09-10 14:34 review
issue9822.v2.diff zach.ware, 2013-02-14 03:56 Updated for 3.4 review
issue9822.v3.diff zach.ware, 2013-02-14 05:29 Version 3, move externals*.bat to PCbuild review
Messages (10)
msg116009 - (view) Author: Sorin Sbarnea (ssbarnea) * Date: 2010-09-10 11:36
Currently most batch files from Tools\buildbot do fail to run if you do not call them from the python source root directory.

I already have patched files, but the question is against which branch should I make them, considering that this bug is valid for all versions?

Do you prefer patch or just the entire files?
msg116013 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-09-10 12:29
The general rule for submitting patches is to make them against development trunk (which is currently the py3k branch).  Unified diffs from the top level of the checkout are preferred; whole files are not useful.

However, it is not clear what bug you are trying to fix here.  Why would the buildbot scripts ever get executed from anywhere except the checkout directory?  They are obviously working just fine as they are, since the buildbots are using them successfully.
msg116015 - (view) Author: Sorin Sbarnea (ssbarnea) * Date: 2010-09-10 12:46
In this case I made the patch on the right branch (py3k).

These scripts could be called manually and it doesn't make any sense not to make them work in all cases.

Not every Windows developer is using Visual Studio to build things, 'some' of them are using the command line, and in this case it does make a sense to be able to call this scripts without these 'strange' limitations.

Implementing this would simplify dev setup/usage on Windows. Also I updated the PCbuild/readme.txt file.
msg116020 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-09-10 13:46
I did not realize the build instructions recommended using the buildbot tool.  It is clearly past time I got around to doing windows build myself.  

Please regenerate the diffs from the top level of the checkout, and we'll see if one of the windows devs feels like checking it in.
msg116021 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2010-09-10 14:16
This is just a guess, but it might have to do with how buildbot works, so I'd be careful of changing this. A lot of things (everything?) in that Tools\buildbot folder depend on being run from the top-level directory in order to work correctly.

Another example: If you run Tools\buildbot\external.bat from a directory other than the top-level, the checkouts will end up in a place that pcbuild.sln doesn't know about, thus various subprojects will not build because they can't find the source.
msg116023 - (view) Author: Sorin Sbarnea (ssbarnea) * Date: 2010-09-10 14:34
This is true, that this can impact the build process but the changes are assuring that it will always chdir to the right directory.

BTW, %~dp0 is the directory when the batch file is located.
msg116212 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2010-09-12 16:21
> I did not realize the build instructions recommended using the
> buildbot tool.  It is clearly past time I got around to doing windows
> build myself.

I'd rather prefer a different setup, also: it would
be better if the batch files to get the sources lived in PC (or perhaps
PCbuild), with Tools/buildbot just referring to them.

> Please regenerate the diffs from the top level of the checkout, and
> we'll see if one of the windows devs feels like checking it in.

If the buildbots continue to work, it's fine with me.
msg182073 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2013-02-14 03:56
I just stumbled across this issue in looking for another issue, and this turns out to be of interest to me as well.  As such, I've updated sorin's patch to apply to the current default branch, added the same kind of change to the new-since-then clean-amd64.bat, and fixed a bug in the initial patch to external-common.bat--it had been doing 'cd /D "%~dp0\.."' instead of "%~dp0\..\..\..".  It also looks like my editor stripped some trailing whitespace in a couple of files.

A much larger change that I made was to switch to using pushd/popd to make the initial dir change, and to return to the calling dir.  It strikes me as good practice not to change directory without warning simply by calling a batch file.  Alternately, things could be switched back to cd /D instead of pushd, and switch popd to "echo Leaving you in %CD%..." just to give some notice of the change.

I can't test whether the change would affect the buildbots, but it doesn't look like it should.  I have tested calling each file from several locations, including the root of the source tree, and everything seems to work as expected.

I will also be attaching a patch that also moves external*.bat into PCbuild as Martin suggested, as that does seem a more natural place for them.
msg182075 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2013-02-14 05:29
Here's the patch that moves external*.bat into PCbuild.  I also took the opportunity to give the three files more descriptive names: external.bat -> get_externals.bat, external-common.bat -> get_common_externals.bat, and external-amd64.bat -> get_externals-amd64.bat.  I'm pretty sure I got all references to them; I know I got everything in PCbuild\readme.txt and in the Tools\buildbot scripts.

As an aside, it seems like my last message caused my avast! to freak out about and refuse to load this page, calling it an HTML:Script-inf virus.  My apologies if anyone else is similarly affected.
msg222499 - (view) Author: Zachary Ware (zach.ware) * (Python committer) Date: 2014-07-07 19:14
Fixed by #21907.
Date User Action Args
2022-04-11 14:57:06adminsetgithub: 54031
2014-07-07 19:14:23zach.waresetstatus: open -> closed

assignee: zach.ware
versions: + Python 3.5, - Python 3.4
messages: + msg222499
superseder: Update Windows build batch scripts
resolution: fixed
stage: resolved
2013-02-14 05:29:38zach.waresetfiles: + issue9822.v3.diff

messages: + msg182075
2013-02-14 03:56:54zach.waresetfiles: + issue9822.v2.diff
versions: + Python 3.4, - Python 3.2
nosy: + zach.ware

messages: + msg182073

components: + Windows
2010-09-12 16:21:15loewissetmessages: + msg116212
2010-09-10 14:34:28ssbarneasetfiles: - buildbot_curdir.patch
2010-09-10 14:34:22ssbarneasetfiles: - readme.txt.patch
2010-09-10 14:34:10ssbarneasetfiles: + path_for_bug_9822_v1.patch

messages: + msg116023
2010-09-10 14:16:06brian.curtinsetmessages: + msg116021
2010-09-10 13:46:37r.david.murraysetversions: - Python 3.1, Python 2.7
nosy: + loewis, tim.golden, brian.curtin

messages: + msg116020

type: compile error -> enhancement
2010-09-10 12:46:54ssbarneasetfiles: + readme.txt.patch

messages: + msg116015
2010-09-10 12:29:47r.david.murraysetnosy: + r.david.murray

messages: + msg116013
versions: - Python 2.6, Python 3.3
2010-09-10 11:38:51ssbarneasetfiles: + buildbot_curdir.patch
keywords: + patch
2010-09-10 11:36:58ssbarneacreate