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.

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

Dev funkin arm64 #3

Merged
merged 54 commits into from
Jul 25, 2024
Merged

Dev funkin arm64 #3

merged 54 commits into from
Jul 25, 2024

Conversation

EliteMasterEric
Copy link
Member

No description provided.

nixbody and others added 30 commits June 10, 2022 23:49
…e included in some toolchains and was deprecated in C++17 anyway).
Casting `const char*` → `char*` is bad form, and we'd rather copy the string than do that. However, `GetGlyphIndex()` now takes a const, so neither workaround is needed.
Also, use `hxs_utf8()` for consistency.
…ets.

If you have a `<section if="cpp">` tag in your project.xml, you don't want it to be active just because a system environment variable happens to be named "cpp". You only want it active if actually targeting C++.
…ble paths from Android SDK

The 'SDK Tools' package located in /tools/ is officially considered 'obsolete', so we should not use it by default.

We now prefer /platform-tools/adb over /tools/adb

We now prefer /emulator/emulator over /tools/emulator

If the newer replacement executables are missing, we still try to fall back to /tools/. This should allow older Android SDKs to continue to work properly.

Additionally, if neither version can be found, we report an error. For adb, we always need it, so we always report an error if it is missing. For emulator, we report an error only if we're actually going to use an emulator.

/tools/android doesn't have a newer alternative. We were running 'android list avds' to get a list of all available AVDs. However, both '/emulator/emulator -list-avds' and '/tools/emulator -list-avds' provide a simple list of AVDs separated by line breaks. So it seems that we never actually needed /tools/android. Plus, it outputs a better format that doesn't require searching every line of the output string for 'Name:', and we can just split and trim. So I completely removed /tools/android and we now use either '/emulator/emulator -list-avds' or '/tools/emulator -list-avds'.
… when they are used only, instead of immediately in AndroidHelper.initialize()

It turns out that adb isn't included GitHub Actions unless you install it specifically. However, you can technically build Android apps with Lime without adb, so we shouldn't report the error in initialize(). Most important is install(), where both adb and emulator are commonly used.

Followup to eed47e7
The former was unclear about how the dependency would relate to web workers. Would it only be available to workers? Would it automatically spin up a worker?

`allow-web-workers` isn't 100% perfect, but it implies the correct answers to the questions above (no and no) and isn't too long.
* Add Drop file event support for android.

* Updated MIME type configuration and intent filter generation.

* "supportedMimeTypes" => "mimeType"

* `mimeType` -> `accept-file-intent`
…nifest.xml

Replace (project.window.fullscreen ? ".Fullscreen" : null) with (project.window.fullscreen ? ".Fullscreen" : "")
…brew/lib to rpath of lime.ndll

Previously, we added these rpaths to lime.ndll when it was built in commits c70ec9f and 333d093, but it's actually necessary only for Neko, so now I made it happen specfically after calling `nekotools boot` to create the Neko executable.

I've tested cpp and hl, and I've confirmed that the executables still launch successfully when these rpaths are omitted. It's better for their security to use fewer rpaths.

As noted commit c70ec9f, adding these rpaths is necessary due to a change in Xcode 15 where /usr/local/lib used to be available on the rpath automatically, but now it isn't, which affects the executable's ability to find the libneko dylib.
joshtynjala and others added 24 commits July 1, 2024 08:53
…nflicts

Ignore system environment variables with the same name as common targets.
[ci] Add mac arm64 ndll to lime package
I'd rather duplicate the SDK version check, not the math.
`GameActivity` doesn't print any other messages, so this seems out of place. Plus, it would happen every time even if there's no vibration ongoing.
UNICODE fixes (clipboard, window title, file dialogs, paths, font glyphs, ...)
…/opt/hombrew/lib to rpath of lime.ndll"

This reverts commit 4793649.

Didn't work with Haxe/Neko installed from Apple Silicon Homebrew because Lime tools couldn't link to Neko.
@EliteMasterEric EliteMasterEric merged commit d1092ec into dev-funkin Jul 25, 2024
15 of 18 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants