Skip to content

x.py: chdir to rust root folder, so that x.py can be called from other directories #42689

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Closed
wants to merge 1 commit into from

Conversation

RalfJung
Copy link
Member

I have my emacs "M-x compile" set up to do ~/path/to/rust/x.py build ..., but emacs will call this from whatever directory the current file is in, which is how I noticed that the working directory does matter for x.py. For example, after changing it, it re-downloads the bootstrap compiler, because that is stored somewhere relative.

Given that cargo also makes it so that the working directory doesn't matter for the build, I felt it'd make sense to implement the same for x.py.

@rust-highfive
Copy link
Contributor

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

@nikomatsakis
Copy link
Contributor

just as a random hint, M-x recompile will keep the directory and command you started with. But yeah =)

@nikomatsakis
Copy link
Contributor

@bors r+

@bors
Copy link
Collaborator

bors commented Jun 15, 2017

📌 Commit 3bb283f has been approved by nikomatsakis

@RalfJung
Copy link
Member Author

RalfJung commented Jun 15, 2017

Hm, I just noticed this chdir screws up clicking on filenames in the errors in emacs. So it's not perfect either. I will look at M-x recompile, but I fear "C-c C-c RET" is already too deep in my muscle memory from LaTeX...

@petrochenkov
Copy link
Contributor

@bors r-
Wait, you are breaking out-of-source builds.
Now rustbuild will create everything in the source directory and not where I'm building.

the working directory does matter for x.py

That's exactly the point.

@RalfJung
Copy link
Member Author

RalfJung commented Jun 16, 2017

Well, but it's annoying for the directory to matter:

$ ./x.py ...
$ cd src
$ ../x.py ... # this will re-download all the bootstraping, and probably recompile other things

@ishitatsuyuki
Copy link
Contributor

I'm against changing cwd. Most of the x.py code is root aware, and invokes the command with an argument to specify target directory.

@shepmaster shepmaster added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Jun 16, 2017
@nikomatsakis
Copy link
Contributor

D'oh, my bad. This seems like an "obviously ok" change, but I should have solicited broader comment.

@nikomatsakis
Copy link
Contributor

I suggest we just close this, and @RalfJung uses M-x recompile instead. =)

@RalfJung
Copy link
Member Author

I'm against changing cwd. Most of the x.py code is root aware, and invokes the command with an argument to specify target directory.

And that target directory is the pwd? I guess I am not sure what you mean by "root aware".

But, well, I can write a little wrapper script for myself.

@arielb1
Copy link
Contributor

arielb1 commented Jun 16, 2017

I use x.py several times in different subdirectories with different config.toml settings (debug assertions vs. release vs. cross etc.), and this would break that.

@RalfJung
Copy link
Member Author

I use x.py several times in different subdirectories with different config.toml settings (debug assertions vs. release vs. cross etc.), and this would break that.

I didn't even know that's possible (changing the config.toml depending on the pwd) -- is this documented anywhere?

Anyway, clearly x.py currently deliberately works the way it works, so I'm going to close this PR.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants