Repository navigation
windows batch files are dependent on cmd current directory #54031
Description
| BPO | 9822 |
|---|---|
| Nosy | @loewis, @tjguk, @bitdancer, @ssbarnea, @briancurtin, @zware |
| Superseder | |
| Files |
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/zware'
closed_at = <Date 2014-07-07.19:14:23.277>
created_at = <Date 2010-09-10.11:36:58.461>
labels = ['type-feature', 'OS-windows', 'build']
title = 'windows batch files are dependent on cmd current directory'
updated_at = <Date 2014-07-07.19:14:23.275>
user = 'https://github.com/ssbarnea'bugs.python.org fields:
activity = <Date 2014-07-07.19:14:23.275>
actor = 'zach.ware'
assignee = 'zach.ware'
closed = True
closed_date = <Date 2014-07-07.19:14:23.277>
closer = 'zach.ware'
components = ['Build', 'Windows']
creation = <Date 2010-09-10.11:36:58.461>
creator = 'ssbarnea'
dependencies = []
files = ['18831', '29068', '29069']
hgrepos = []
issue_num = 9822
keywords = ['patch']
message_count = 10.0
messages = ['116009', '116013', '116015', '116020', '116021', '116023', '116212', '182073', '182075', '222499']
nosy_count = 6.0
nosy_names = ['loewis', 'tim.golden', 'r.david.murray', 'ssbarnea', 'brian.curtin', 'zach.ware']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = '21907'
type = 'enhancement'
url = 'https://bugs.python.org/issue9822'
versions = ['Python 3.5']
Activity
ssbarnea commentedon Sep 10, 2010
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?
bitdancer commentedon Sep 10, 2010
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.
ssbarnea commentedon Sep 10, 2010
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.
bitdancer commentedon Sep 10, 2010
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.
briancurtin commentedon Sep 10, 2010
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.
ssbarnea commentedon Sep 10, 2010
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.
loewis commentedon Sep 12, 2010
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.
If the buildbots continue to work, it's fine with me.
zware commentedon Feb 14, 2013
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.
zware commentedon Feb 14, 2013
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.
zware commentedon Jul 7, 2014
Fixed by bpo-21907.