-
-
Notifications
You must be signed in to change notification settings - Fork 416
Fix RunScript to use local haxelib paths.
#1992
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Conversation
|
Haven't tested this, but the code looks fine. |
|
It seems like there are a lot of weird edge cases with how lime interacts with local |
Before `Sys.setCwd()` would only be run in the `rebuild tools` case, where it would always been cleaned up. The previous patch changed it so that Sys.setCwd runs for all cases, even if it won't be cleaned up. This patch corrects that error, and once again makes sure that setCwd is only run for `rebuild tools`.
|
Prior to #1873, Here is how to reproduce the issue:
|
Oops! Looks like we've overlooked that for a while now. I just added commit 49d81a6 to have GitHub Actions build run.n. |
We also need a way to keep the |
|
Ideally, run.n wouldn't be committed at all, and everyone who checked out the Lime repo would need to build it themselves like they need to rebuild the native binaries. I don't think that there's a good way to keep run.n updated in the repo except to do it manually from time to time. |
|
I feel like it should be possible to automate somehow. We're just looking for PRs that touch RunScript.hx without touching run.n. |
|
Checking for RunScript changes wouldn't catch hxp changes, but I guess if we caught RunScript changes, it might be easier to force a manual update using that as a mechanism. |
This pr makes it so it uses the working directory when searching for lime's path this mainly ensures that if theres a local lime installed, itll use the tools from that lime and not from the globally installed lime.