Getting started with OpenFL and Haxe in VSCode: My first-time experience

Yes, I think you should be able to use the auto-generated task instead with this:

"preLaunchTask": "lime: build html5 -debug"

This has the following advantages:

  • it would automatically use the full list of problem matchers ("$haxe" is just one of several, so some errors wouldn’t work correctly for you)
  • it respects the "haxe.taskPresentation" setting
  • it respects the "haxe.enableCompilationServer" setting
  • it respects the "haxe.executable" and "lime.executable" settings

The downside is that you have to have “HTML5” and “Debug” selected in the status bar for the task to exist.

Is it possible to make all build tasks always available, regardless of which items are selected in the status bar? Personally, I’d rather not need to click around in the UI to get it into the right state first, when the quicker option could be to select a different item in the task list. I understand if there’s some technical limitation that makes this impossible, of course. It just seems like extra steps to me.

It’s actually not really a technical limitation, but consider this:

  • there’s 5 tasks for the different commands right now (build, test, update, clean, run)
  • there’s currently 8 (!) targets to choose from, with HashLink yet to be added sometime in the future
  • there’s 3 build configurations, debug, release and final

If you multiply all that out, there would be a total of 120 tasks. That just seems like way too much. :slight_smile:

I’ve been discussing this with Joshua a bit, I think what we would want here is the possibility for task providers to contribute hidden tasks, so that all tasks always exist to be used in debug configs, but don’t pollute the UI as much (only the active ones wouldn’t be hidden).

Oh, and also: the picker has more purposes than just selecting the target to use for tasks. It also changes the code completion arguments. This is necessary for completion to work properly for platform-specific APIs and conditional compilation blocks like #if js.

And you don’t have to click around in the UI, everything is bound to commands you can assign shortcuts to. I have this in my keybindings.json:

{
    "key": "ctrl+e",
    "command": "haxe.selectDisplayConfiguration",
    "when": "haxeCompletionProvider == 'Haxe'"
},
{
    "key": "ctrl+e",
    "command": "lime.selectTarget",
    "when": "haxeCompletionProvider == 'Lime'"
}

Yeah, that would be way too many tasks to show. My initial thought was that you could hide tasks for all but the current target, but then I guess it would be somewhat inconsistent. You don’t want the UI state controlling the visibility of some tasks, but not others.

Yes, this sounds good. I wasn’t aware that a task could be defined by an extension, and hidden from the UI. I’ll have to look into that.

In addition to making it possible to reference any task with preLaunchTask in launch.json, I think that it would also allow someone to force a task to always be visible by referencing it in their workspace’s tasks.json. That would give people control over which tasks are shown, which seems like it covers my request well enough.

Well, that’s the problem actually, the second part is currently not possible. We’re probably going to open a feature request on the VSCode repo for it and see how that goes.

Can anyone help with this. I’m trying to run my project from VC but no way.
Is there any minimal project how to run and debug with VS code?

The "type" should be "chrome", not "Chrome". Also, you need to have the Chrome debugger installed.

OK, now it open chrome on localhost port 3000 but I get empty web page even if I point

"webRoot": "${workspaceFolder}/bin/html5/bin/index.html"

Also for the flash:

You need to run the lime test html5 task beforehand for there to actually be a webserver running for the debugger to connect to.

Your Flash launch config seems to have some debug:flash preLaunchTask that doesn’t exist.

Everything works now but for the flash I must explicitly write file name:
"${workspaceFolder}/bin/flash/bin/WordCrush.swf" -this works
but this won’t:
"${workspaceFolder}/bin/flash/bin/${APPLICATION_FILE}.swf"

Yes, you’re not meant to use the latter as-is. Did you copy that from flixel-templates? APPLICATION_FILE is replaced with the correct value when running flixel-tools.

Yes, I copy it from flixel-templates. I was think {$APPLICATION_FILE} is internal haxe variable. Is there a way to put file name into variable in openfl VC project?

I don’t think so.

Anyway, this should all be solved with the next release of the Lime extension, where you will only need a single “lime” launch config that automatically populates the parameters for the selected target’s debugger. :slight_smile:

2 Likes

Our Lime VSCode extension has just been updated to 1.3.0 with a number of great changes – including intial debugger support!

EDIT: HashLink and debugger support both require Lime 7.3 or greater – to be released.

Here are the steps:

1.) Select “HTML5” (or “HTML5 / Debug”) from the target configuration selection
2.) Select “Debug” > “Start Debugging”
3.) The first time you will be prompted to select which debugger to use. Select “Lime” from the list and it will create an auto-generated launch config JSON for you
4.) Select “Debug” > “Start Debugging” again

The plugin uses the “Debugger for Chrome” extension by default, but you can also go to Settings and change the “lime.browser” setting to Firefox or Edge if you prefer (these require the “Debugger for Firefox” or “Debugger for Edge” extensions, respectively)

EDIT: There are surely ways that the extension can still be improved – contributions welcome :smile:

4 Likes

To add to what Joshua said - a launch config is only auto-generated if you don’t already have a launch.json. If you do, just add this configuration:

{
	"name": "Selected Target",
	"type": "lime",
	"request": "launch"
}

Right now this supports HXCPP, JS and Flash debugging, with HL support coming soon.

I checked out the code from Github yesterday to give the lime launch a try, and it’s working nicely for me! :smile:

1 Like

Yesterday and today, I tried building an OpenFL app for Android, and I ran into some issues.

I assumed that I could simply install Android Studio, and it would provide the correct SDKs, but I guess that’s not the case. I ran lime setup android and specified the paths to the SDKs that Android Studio downloaded. When I tried lime build android, I was getting this error:

arm-linux-androideabi-g++ is not recognized as an internal or external command

(I’m on Windows 10, by the way)

I found a couple of topics here in the forums mentioning that error, but no clear solution.

I found the Lime: Setup Android page that suggested specific versions of certain packages, so I figured that something must be wrong with using the latest SDK/tool versions. However, I determined that Android Studio lacks the capability to choose specific versions of certain tools, and my best guess is that this is probably why the Android build was failing for me when I used Android Studio to install the SDKs.

In the end, I ended up manually downloading the SDK and NDK and installed everything from the command line using sdkmanager.bat. However, even then, there were some issues.

Here was my first attempt to install what was needed, based on the versions mentioned in the Lime docs:

sdkmanager.bat "platform-tools" "platforms;android-19" "build-tools;24.0.1"

I also manually downloaded NDK version r13b, as suggested in the docs.

My first build attempt with the new SDKs ended up with some error mentioning “Android 26”. So, I tried installing that platform version instead of 19:

sdkmanager.bat "platforms;android-26"

This seemed to work better because the build made it further in the process, but then I got this error:

:deps:extension-api:processReleaseResources FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':deps:extension-api:processReleaseResources'.
> com.android.ide.common.process.ProcessException: org.gradle.process.internal.ExecException: Process 'command 'c:\Users\josht\Development\Android\sdk\build-tools\24.0.1\aapt.exe'' finished with non-zero exit value -1073741819

I next tried to install a newer version of build-tools:

sdkmanager.bat "build-tools;28.0.3"

One more build, and I finally found success! I tried lime test android next, and the app opened on my device connected over USB.

If it’s possible to get this working with Android Studio, I think that the process needs to be be documented because Google’s page strongly encourages you to download Android Studio to get the SDK. I don’t think that everyone is going to figure out that they need the standalone SDK when things fail with Android Studio, or how exactly to find it.

The versions of the various tools that are required to build for Android should probably also be updated on the Setup Android page too, assuming that they are indeed out of date, as they seemed to be here.

I do not necessarily feel confident that I have everything set up correctly or in the simplest way possible, and I’m wary of the idea that something might break unexpectedly in the future if I ever update Lime.

1 Like

Thanks Josh

We usually find that Google’s tools work best if you have the latest version of the platform build tools – I can’t think of a time that we’ve needed to recommend that they be downgraded.

It is possible to use custom SDK versions through <config:android target-sdk-version="" /> but we do need to pick something. We currently target API 26 because this is the latest version of the SDK that we directly use features from – but this is not the minimum – we support back to around API 11 (I believe).

The sticky wicket right now is that HXCPP lacks clang support for Android, GCC support was removed in Android NDK 16. I have a pull request where I was working on this issue: https://github.com/HaxeFoundation/hxcpp/pull/707 (it appears there is also a newer one: https://github.com/HaxeFoundation/hxcpp/pull/742)

Hopefully this can be resolved and we can just say “install the latest”

Android Studio (on Linux) asked me to unzip “wherever”… I’m not sure if there would be a way for us to check an environment variable or standard install and discover the SDKs ourselves, or to know that you only have a newer API version installed?

You may be able to auto-detect some things on Windows and macOS. Android Studio installed the SDK on my machine in c:\Users<username>\AppData\Local\Android\Sdk. Somebody on StackOverflow says that it’s /Users//Library/Android/sdk on macOS.