Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Mac builds broken #1122

Open
GreenMatthew2019 opened this issue Oct 9, 2023 · 9 comments
Open

Mac builds broken #1122

GreenMatthew2019 opened this issue Oct 9, 2023 · 9 comments
Labels
good first issue Good for newcomers

Comments

@GreenMatthew2019
Copy link

I have down loaded the software (for Mac) and run the ltn.exe
I now have a terminal window open.
what do I do next to get started?
@dabreegster
Copy link
Collaborator

I don't have a Windows or Mac machine myself to test on, so starting the software there is unfortunately broken. Try opening the ltn executable inside the binaries folder -- does that do anything?

@GreenMatthew2019
Copy link
Author

GreenMatthew2019 commented Oct 9, 2023 via email

@dabreegster
Copy link
Collaborator

Sorry, I'm not sure how to fix this without access to a Mac to try things out. This is an open source project; if anyone's reading this and can help get the Windows and Mac builds working better, help much appreciated.

In the meantime, stick with the web version: https://play.abstreet.org/0.3.48/ltn.html and let me know if you need a new area imported (not possible on the web version, unfortunately)

@dabreegster dabreegster changed the title getting started Mac builds broken Oct 9, 2023
@dabreegster dabreegster added the good first issue Good for newcomers label Oct 9, 2023
@GreenMatthew2019
Copy link
Author

GreenMatthew2019 commented Oct 9, 2023 via email

@dabreegster
Copy link
Collaborator

I can at least get that area added to the web version today. The image in your email didn't come through to Github; does this cover it?
Screenshot from 2023-10-09 13-00-44

@GreenMatthew2019
Copy link
Author

GreenMatthew2019 commented Oct 9, 2023 via email

@dabreegster
Copy link
Collaborator

Try this out and let me know if you hit problems: https://play.abstreet.org/0.3.48/ltn.html?system/gb/darlington/maps/center.bin

@andrewphilipsmith
Copy link
Collaborator

I think I can reproduce this. The behaviour I find is:

  • If the current working directory is inside the the expanded zip file (typically abstreet_mac_v0_3_48) then the binary launches correctly.
  • If cwd is a directory outside the expanded zip file, then launching the binary will fail.

How to reproduce

  1. Download https://github.com/a-b-street/abstreet/releases/download/v0.3.48/abstreet_mac_v0_3_48.zip and save in to the default Downloads directory.
  2. Unzip by double clicking. This will expand the zipfile into a Downloads/abstreet_mac_v0_3_48 directory.
  3. Open a terminal. The default cwd is the user's home directory
  4. Attempt to launch one of the applications, either directly from the binary, or via the wrapper shell scripts
user@host ~$ Downloads/abstreet_mac_v0_3_48/binaries/ltn                                                                                        127 
thread 'main' panicked at 'Can't find the data/ directory', abstio/src/abst_paths.rs:54:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
user@host ~$ Downloads/abstreet_mac_v0_3_48/ltn.sh                                                                                              101 ↵  
See logs in output.txt

(Untested, but I suspect that the same baviour would occur on Windows and Linux)

Workaround

  1. Change directory in the terminal to the expanded zip directory:
user@host ~$ cd Downloads/abstreet_mac_v0_3_48

(Note that your prompt might look different to the above - ie everything before and including the $ sign)

  1. Launch the app:
user@host ~/Downloads/abstreet_mac_v0_3_48$ binaries/ltn

@GreenMatthew2019 Please could you let us know if this workaround helps you? Feel free to ask if you've any other questions.

Possible fixes

@dabreegster Some ideas for longer-term fixes:

  • We could make the wrapper scripts more robust, by detecting their own location, rather than assuming that the cwd is correct (See Mac/Linux https://stackoverflow.com/a/59916, Windows https://ss64.com/nt/syntax-args.html)
  • We could improve the search for the data directory. I think at present if uses the cwd, rather than the binary location as the start point for its search
  • We could improve the error message, when it fail to find the data fdir, to be more actionable.

@dabreegster
Copy link
Collaborator

Fantastic debugging + write-up, thank you!

We could improve the search for the data directory

abstreet/abstio/src/abst_paths.rs

Line 22 in f8e5d5f

} else if file_exists("data/".to_string()) {

Rather than use the current directory as the base, we could try https://doc.rust-lang.org/std/env/fn.current_exe.html after stripping off the executable?

The variations of ../, ../../, etc in there are so that you can launch tools from different cases in the release binaries, from git, etc. For example cd abstreet/apps/ltn/src; cargo run would require us to find ../../data. Maybe there's a much saner way to do this though?

We could make the wrapper scripts more robust, by detecting their own location

This sounds useful. If somebody directly opens the exe, it'd still break, but be an improvement.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
good first issue Good for newcomers
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@dabreegster @andrewphilipsmith @GreenMatthew2019