Android builds with native extensions fail (DEF-3026)

dapetcu21 · 2017-12-03 18:20:06 UTC

Bundling with the editor fails with only this output:

[options] bootstrap class path not set in conjunction with -source 1.6

The error that I’m getting with bob.jar is:

Exception in thread "main" com.dynamo.bob.MultipleCompileException: Build error
	at com.dynamo.bob.bundle.BundleHelper.buildEngineRemote(BundleHelper.java:298)
	at com.dynamo.bob.Project.buildEngine(Project.java:648)
	at com.dynamo.bob.Project.doBuild(Project.java:742)
	at com.dynamo.bob.Project.build(Project.java:339)
	at com.dynamo.bob.Bob.main(Bob.java:331)
Caused by: com.defold.extender.client.ExtenderClientException: Failed to build source.
	at com.defold.extender.client.ExtenderClient.build(ExtenderClient.java:78)
	at com.dynamo.bob.bundle.BundleHelper.buildEngineRemote(BundleHelper.java:290)
	... 4 more

It might be related to: https://github.com/defold/editor2-issues/issues/1295

UPDATE: I just now saw that the issue is still open, so I might have opened a duplicate. Oops.

Mathias_Westerdahl · 2017-12-04 08:55:21 UTC

Hmm, I think it’s good that you did
I did fix that first issue (it arrived in 1.2.116), but I unfortunately missed that I got that bug assigned back for some reason (I will close that ticket)
The actual issue then was that the error reporting was broken. That was a fix in bob.jar.

I just tried to bundle our Android native extension example with the latest Editor 2 (909862a870081f044e0592fe1263f68309a24868 / 4ac025d15c25a9e0dbf14140d2e5d443c2edfdc4) and that worked fine.

Perhaps you could try to bundle that example?

EDIT: I got the same issue now as well I’m looking into it asap!

Mathias_Westerdahl · 2017-12-04 15:13:01 UTC

I have now a pull request in review for this issue. Unfortunately I don’t have a good workaround for you until this fix lands in the next release (or Editor 1 alpha). I got to see more of the actual log if I bundled for iOS (which doesn’t have that bootstrap class warning).

dapetcu21 · 2017-12-04 21:55:51 UTC

Yeah. Couldn’t reproduce with the Android native extension example. It still does that with my project, though. I’ll wait until the fix lands and test then. Thanks for the quick as always response.

Mathias_Westerdahl · 2017-12-07 08:52:20 UTC

After some more work on this, the improved error handling is in the alpha version of Editor 1 now . Then you should at least be able to unblock yourself. (Next proper release with Editor 1+2 is scheduled for tuesday)

dapetcu21 · 2017-12-07 18:40:43 UTC

I tried the Editor 1 alpha and it fails someplace else when building. This stack trace and an “Unknown error” in a Spine scene is all I have. The same spine scene compiles with no issues in Editor 2. Granted, this happens on a hand-edited Spine JSON (I added events manually because DragonBones doesn’t export them properly and our paperwork isn’t yet done to buy Spine licenses).

Meanwhile, getting back on point, I’ll try to remove that scene and build again.

java.lang.NullPointerException
	at com.dynamo.bob.util.SpineSceneUtil.loadAnimation(SpineSceneUtil.java:469)
	at com.dynamo.bob.util.SpineSceneUtil.loadAnimations(SpineSceneUtil.java:562)
	at com.dynamo.bob.util.SpineSceneUtil.loadJson(SpineSceneUtil.java:730)
	at com.dynamo.bob.pipeline.SpineSceneBuilder.build(SpineSceneBuilder.java:387)
	at com.dynamo.bob.Project.runTasks(Project.java:899)
	at com.dynamo.bob.Project.doBuild(Project.java:733)
	at com.dynamo.bob.Project.build(Project.java:339)
	at com.dynamo.cr.editor.builders.ContentBuilder.buildLocal(ContentBuilder.java:154)
	at com.dynamo.cr.editor.builders.ContentBuilder.build(ContentBuilder.java:81)
	at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:726)
	at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199)
	at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:321)
	at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:396)
	at org.eclipse.core.internal.resources.Project$1.run(Project.java:618)
	at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
	at org.eclipse.core.internal.resources.Project.internalBuild(Project.java:597)
	at org.eclipse.core.internal.resources.Project.build(Project.java:124)
	at com.dynamo.cr.editor.handlers.LaunchHandler$1.run(LaunchHandler.java:153)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

Here’s the JSON: Archive.zip (1.2 KB)

dapetcu21 · 2017-12-07 18:53:33 UTC

After removing that spine file and trying to bundle for Android with Editor 1, the build fails silently. It created an armv7-android dir with an empty report.html, but that’s about it.

Bundling for macOS works as expected.

Mathias_Westerdahl · 2017-12-07 22:20:48 UTC

Hmm, weird that the spine scene behaves so differently between the editors

As for the silent error, very annoying, perhaps you can invite me to your project and I can have a look tomorrow? (mathias.westerdahl at king.com)

dapetcu21 · 2017-12-08 11:20:15 UTC

Thanks! I added you . You can also reach me on Slack if you encounter any issues.

Mathias_Westerdahl · 2017-12-08 14:21:02 UTC

Ok, I found two things:

the spine scene is missing a global event list, so when you are referencing events that are not there, you get a null event (Added DEF-3039 for this). I added this at the top scope to make it work. This is from orbit1.json. (Note the “play_animation_orbit2” name and vice versa!)

{
  "bones": [
    {
      "name": "root",
      "length": 0
    },
    {
      "length": 0,
      "name": "revolving_bone",
      "parent": "root"
    },
    {
      "y": -200,
      "length": 0,
      "name": "my_bone",
      "parent": "revolving_bone"
    }
  ],
  "events": {
    "play_sfx" : {"int": 0, "float": 0, "string": "casefile_open" },
    "play_animation_orbit2" : { "int": 0, "float": 0, "string": "pulse" }
  },
...

The actual compile error was from the fact that defos doesn’t support android yet, so you get a linker error. Perhaps @Pkeod could add a null-implementation for it? E.g. adding the C++ symbols, but not registering a defos Lua module, so the user can check for it?

As for the lack of output, I’m adding this use case to the supported messages (and unit tests).
What we currently do it that if we fail to parse a recognised line, we will put the entire log in the exception. So if you select “Properties” on the error (“Problem”), and then view that (ridiculously) small text edit, you can find the actual log:

Pkeod · 2017-12-08 14:34:52 UTC

I’ve made an issue for this https://github.com/subsoap/defos/issues/40

I can do it but not right away, anyone else who has time right now is welcome to check this out.

dapetcu21 · 2017-12-09 21:25:44 UTC

Yup. The PR solved the android build issue and declaring my events in the “events” object solved the Spine issue. Thanks a lot for the help!