libgdx / gdx-jnigen Goto Github PK

AntScriptGenerator prefixes the libsDir path with ../, preventing the libs directory from being specified as an absolute path (e.g. from the Gradle plugin as `libsDir = "${project.buildDir}/jnigen/libs"). For background, I'm attempting to set up a project where all the jnigen artifacts are placed within the Gradle build directory (to allow easy clean-up).

Hi there.
Its a possible to make cross builds for *nix from windows by default ant tasks generated by plugin or i must compile win lib at Windows and *nix at Linux separately?

version: 2.3.1
os: mac 10.14.6
java version: 1.8.0_221

Generating C/C++ for 'src/main/java/io/nondev/nonlua/Lua.java'...
Command: javac -classpath "target/classes:/Users/playcrab/developer/LuaJIT/classpath/gdx-jnigen-2.3.1.jar" -d /var/folders/2q/s0zwfxm12q7d4qd0y3gggld80000gn/T/gdx-jnigen216518143776182492 -h jni src/main/java/io/nondev/nonlua/Lua.java
src/main/java/io/nondev/nonlua/Lua.java:27: �误: ���com.badlogic.gdx.jnigen���
import com.badlogic.gdx.jnigen.JniGenSharedLibraryLoader;
                              ^
src/main/java/io/nondev/nonlua/Lua.java:28: �误: ���io.nondev.nonfilesystem���
import io.nondev.nonfilesystem.Files;
                              ^
src/main/java/io/nondev/nonlua/Lua.java:38: �误: ���符�
    private static native CPtr jniOpen(int stateId); /*
                          ^
  符�:   类 CPtr
  �置: 类 Lua
src/main/java/io/nondev/nonlua/Lua.java:42: �误: ���符�
    private static native void jniClose(CPtr cptr); /*
                                        ^
  符�:   类 CPtr
  �置: 类 Lua

Verify and figure out why.

Hi,
I opened an issue in libgdx/libgdx while trying to find a work around to a split package issue (this one: libgdx/libgdx#7355) and would like to ask if it was possible to change the gdx-jnigen-loader package com.badlogic.gdx.utils name to anything else?

TL:DR; Since gdx (v1.12.1) depends on jnigen (v. 2.4.1), and gdx itself is not modularized, even if you're not using jnigen yourself, jnigen becomes a transitive dependency (I think that's the word for it) and causes problems for your project either way.
Nothing prevents gdx from being used in a modular application as far as I can tell, as java can automatically infer it as a module if put on the module path. However, gdx requires jnigen to be present as well, which is why I haven't been able to find a workaround.

Admittedly, I don't have a full comprehension of what this will cause of problems for libgdx itself, but I'm hoping it could be a part of the next release cycle (https://github.com/libgdx/libgdx/milestone/6) and I should personally like to help in any way I can.

Edit: I went through the closed issues to see when if this had been brought up before, and it kind of has: #2 <- the SharedLibraryLoader-merger (the class that causes a ClassNotFoundException if jnigen isn't included as a module in a modular project). I'm not sure the split package issue didn't exist then, but it sounds like what I'm experiencing is an accident following that merger.

Instead of having two implementations SharedLibraryLoader and JniGenSharedLibraryLoader we should probably unify to a single implementation with no other dependencies.

A quick example would be PokeMMO@c9c41d3

This would be a slightly breaking change for libgdx as a whole, which replaces GdxRuntimeExceptions with regular RuntimeExceptions. (Or potentially a new custom typed JnigenRuntimeException)

Would this exception class change be an issue?

Edit: I guess we could also just move GdxRuntimeException to this instead of gdx base. I don't really like that idea, but it would work and not break anything.

Reposting in correct repo-

When using a fresh download of the latest build of Jnigen (with and without the template), it gives the following error on the Windows build:

Property "env.PATH" has not been set

It then searched the global path for this:
[available] Unable to find x86_64-w64-mingw32-g++

If you manually add '.exe' to the compiler-suffix in the XML files, it removes it every build and is then unable to actually run the compiler (which exists and is in the path).

Which then leads to the following string of errors:

Property "compiler-found" has not been set
create-build-dir:
Skipped because property 'has-compiler' not set.

compile:
Skipped because property 'has-compiler' not set.

link:
Skipped because property 'has-compiler' not set.

strip:
Skipped because property 'should-strip' not set.

And then ant cannot run.

Please select the affected platforms

• Android
• iOS
• HTML/GWT
• [x ] Windows
• Linux
• MacOS

jnigen doesn't currently use a plugin marker artifact as it doesn't use the java-gradle-plugin which would automate this task.

In the kotlin gradle DSL this means that the jnigen extension won't be available, and if the plugin is applied with the current readme instructions, it will require this to be configured:

jnigen {
  // this will not work and will throw an error for a missing symbol
}

extensions.configure<JnigenExtension>("jnigen") {
  // configuration goes here
}

A workaround for this is to declare custom plugin resolution rules:

// root settings.gradle.kts
pluginManagement {
    // required because jnigen isn't published as a plugin, and it doesn't have a marker artifact
    // https://docs.gradle.org/current/userguide/plugins.html#sec:plugin_markers
    resolutionStrategy {
        eachPlugin {
            if (requested.id.id == "com.badlogicgames.gdx.gdx-jnigen") {
                useModule("com.badlogicgames.gdx:gdx-jnigen-gradle:2.5.1")
            }
        }
    }
    repositories {
        mavenCentral()
        gradlePluginPortal()
    }
}

Then, the plugin can be applied via the plugins block in the build.gradle.kts file, and jnigen will be available as an extension:

// build.gradle.kts
plugins {
    id("com.badlogicgames.gdx.gdx-jnigen")
}

jnigen {
  // this will now work
}

I don't think either is optimal, but it could be useful to explain it in the readme file. An alternative (which imho would be better also for .gradle files) would be to actually use the java-gradle-plugin so that the plugin will be published correctly.

I'd be happy to make a PR for either solution, let me know if that's something you'd be interested in!

Currentlly, the jnigen build will silently fail, if "has-compiler" evaluated to false.
The failure is noticable by the lack of any log by someone who knows jnigen, but not unfamilair users.
It would be very user friendly to let the gradle task just fail, if a compiler is not present. Preferably with a meaningful error messag.

Currently jnigen (or the gradle plugin) seems to require iOS builds to support armv7, arm64 and x86_64:

(Background: I am trying to link LuaJIT v2.1 in a project but LuaJIT just won't build for 32-bit iOS (without some downgrading hacks) (LuaJIT/LuaJIT#468).)

Is it possible to split the current template and make it optional to build for armv7 iOS? Thank you!

When doing generateHFiles(), javac outputs header files that have a prefix of underscored package name. This then breaks the H file detection as it expects it to start with the class name.

macOS's dylib supports multiple archs in a singe universal dylib file. This enables usage of "upgraded" arch "slices" like x86_64h which includes haswell+ optimizations.

With macOS arm coming up, we should discuss moving dylib to a single universal dylib for simplicity, or doing the same arm split we do for other platforms.

The compiler options would probably look something like -arch arm64 -arch arm64e -arch x86_64 -arch x86_64h

Further reading:
https://developer.apple.com/documentation/xcode/building_a_universal_macos_binary
https://stackoverflow.com/questions/45917280/what-is-the-minimum-supported-sse-flag-that-can-be-enabled-on-macos.

Issue details

Javah has been removed since java 10. It would be very nice to see, if jnigen supported javac -h instead of javah, or maybe both by checking the current java version.
Article about the removal: https://openjdk.java.net/jeps/313

Reproduction steps/code

public static void main(String[] args) throws Exception {
        NativeCodeGenerator jnigen = new NativeCodeGenerator();
        jnigen.generate("X/src/main/java", "X/target/classes", "jni", new String[
        {"**/X.java"}, null);
}

Version of LibGDX and/or relevant dependencies

Jnigen: 1.9.8

Stacktrace

Exception in thread "main" java.io.IOException: Cannot run program "javah": CreateProcess error=2, The system cannot find the file specified

Here is the method from the "NativeCodeGenerator" class.

private void generateHFile(FileDescriptor file) throws Exception {
        String className = this.getFullyQualifiedClassName(file);
        String command = "javah -classpath " + this.classpath + " -o " + this.jniDir.path() + "/" + className + ".h " + className;
        Process process = Runtime.getRuntime().exec(command);
        process.waitFor();
        if (process.exitValue() != 0) {
            System.out.println();
            System.out.println("Command: " + command);
            InputStream errorStream = process.getErrorStream();
            boolean var6 = false;

            int c;
            while((c = errorStream.read()) != -1) {
                System.out.print((char)c);
            }
        }
    }

• Android
• iOS (robovm)
• iOS (MOE)
• HTML/GWT
• Windows
• Linux
• MacOS

Currently plugin generate script whos can't find installed minGW compiler binary at Windows - as result: compilation failed.

Part of verbose ant build log output:

[available] Searching C:\mingw64\bin (Compiler binary 100% exist here)
[available] Unable to find x86_64-w64-mingw32-g++ (Seams build script try to find binary without exe extension)

The jnigen task for gdx-freetype e.g. hangs indefinitly, if the system encoding is ASCII.
Best way might be to enforce UTF-8 encoding for javah call.

When I want to add a new form of CPU architecture to this project, how can I test its success

See libgdx/libgdx#6881

Currently the ant script runs with the "clean" option. Is there a way to not have it do that?

I am building and linking to a rather large library and there is much which has to be built for every little change.

Hi,

I came across problems when loading a shared library on Android (I was trying to setup FreeType).
The log tells me: "Couldn't load shared library 'gdx-freetype' for target: Linux, 32-bit"
I debugged a little and found that in my case the method mapLibraryName() returns the same String that was handed over ("gdx-freetype"). It seems to me, that the method mapLibraryName() does not work properly (on Android) as for Android devices 'isLinux' is set to false when 'isAndroid' is set to true when checking the runtime name. But.... 'isAndroid' is not used in mapLibraryName() at all.
I am using Libgdx 1.9.12 and was testing on an old Nexus 6 with Android 6.
Is this a general issue or maybe just related to the old SDK version that I was using?

Best Regards,
Jochen