Bullet-Native Artifacts building not part of run task

[MeFisto94]

See #1255,
unfortunately assemble doesn't seem to be the right target for run either.

Assemble assembles the whole project, run invokes compileJava and later jar on the individual projects.
Our problem is that this native task touches multiple subproject, so we cannot use their jar task.

I guess we should fix this by adding run.dependsOn(task) in addition to assemble, unless someone has a more clever approach?

[stephengold]

I thought native libraries are supposed to be built ONLY if buildNativeProjects = true in the gradle.properties file. Have you tested it that way?

[MeFisto94]

Sorry for being imprecise:
You are correct, however when buildNativeProjects = false, we should download the prebuilt .zip file with the .dll's and .so's. THIS is what is only happening for build and after #1255 also for assemble (build = assemble + test).

Now when launching gradlew run the tests open up, but for instance launching the first test in the search for PBR is crashing because that dll is missing until you invoke gradlew assemble first.
Thus run needs to depend on assemble or maybe there is a more precise catch-all-task which is invoked by both run and assemble, but before jarring.

[stephengold]

https://docs.gradle.org/current/userguide/base_plugin.html#sec:base_tasks

Tasks that build or download the native libraries should attached (directly or indirectly) to the "assemble" task.

[MeFisto94]

But when you checkout the engine and run ./gradlew run then it will build without the assemble target, meaning you cannot run the tests [at least some of them will fail with an exception, try it!]

[MeFisto94]

I prepared a Pull Request, but didn't submit it, because:

So, as assemble doesn't seem to be executed in this case, we just make run depend directly on extractPrebuiltNatives.
The only thing risky here (I did not test it, sorry), is the order of dependencies, i.e. the natives could be extracted after the engine has been built.

In general I think we should change the build so that a) every submodule (i.e. jme3-bullet-native, ...) depend on the extract task and also investigate why the build doesn't fail when there are NO natives at all, neither extracted nor self-compiled. Maybe we should ensure that the build fails, when the natives couldn't be extracted (I guess it just jar's the whole folder and doesn't care about the contents right now)

[MeFisto94]

So, #1260 didn't fix the issue for the SDK, because actually processRessources, compileJava, classes and jar are invoked but neither assemble nor build.

For the SDK, I will just invoke gradlew assemble once, but we might want to add something like jme3-bullet-native:jar etc dependOn the unzipTask, so instead of adding the dependsOn in the main script, we could add it on the individual subprojects.

That would actually be the cleanest way and the only way it works when directly invoking a build only for the jme3-bullet-native module, e.g.

[stephengold]

I've tripped over this issue several times now. @riccardobl can you provide a proper fix for it?

[stephengold]

Since jme3-bullet-native was removed from the Engine on 26 February 2021, this issue no longer applies. Closing...