get the sdk path to find the executable on linux

[lyonbeckers]

The method for running the PlaydateSimulator on Linux assumes that it's in your PATH. The desktop file that gets set up from the setup.sh script in the linux Playdate SDK just executes it from the SDK path, so I figure it's probably safe to do it the same way

[lilyinstarlight]

Could we maybe have it try to execute PlaydateSimulator first and if that fails, then fallback to trying something based on the SDK path, maybe on all platforms?

This change would break running the simulator from crank on my system, but I admittedly have an uncommon setup so I can just patch crank or work around this if generalizing this behavior is undesired by the maintainers

[lyonbeckers]

I think that's a good idea, I was considering making this change for all platforms, but noticed both Windows and Mac get some kind of installer, so I assumed there's less variability in the way the environments might be set up. I haven't tried the SDK on either Mac or Windows so I wasn't sure. I'll try a fallback for this cfg in the meantime

[boozook]

error: the feature lang_items is internal to the compiler or standard library

This is something new. Did I miss something? Is this feature was renamed or denied somehow? 🤔

[boozook]

LGTM, but what about error on CI? 🙄

[lyonbeckers]

Looks like it might be something new on nightly, I found this tracking issue for adding an internal_features lint, and based on the error message, it sounds like it's set to deny by default https://github.com/rust-lang/compiler-team/issues/596

[boozook]

Seems to you're right 🙄

[lyonbeckers]

Updated on my machine, then tried adding an #![allow(internal_features)] to crankstart's lib.rs but that doesn't seem to have done it for me 😬

EDIT: Would have probably worked better if I had actually put it into the right directory, oops. It does work lol

[boozook]

Looks like fixed:

• job
• PR

[boozook]

@lyonbeckers @lilyinstarlight important message