libgdx / gdx-jnigen

jnigen is a small library that can be used with or without libGDX which allows C/C++ code to be written inline with Java source code.
Apache License 2.0
59 stars 26 forks source link

Add instructions on how to use it with gradle kotlin DSL #58

Closed fourlastor closed 5 months ago

fourlastor commented 6 months ago

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!

Berstanio commented 6 months ago

I think adding a plugin marker artifact is the right way to go, I don't see any downside of it.

Regarding the java-gradle-plugin, I looked through it and it states but only if the [Plugin Publishing Plugin](https://plugins.gradle.org/docs/publish-plugin) has also been applied., so I think further configuration is still needed? In any case, I would have no real objections against the java-gradle-plugin, if it is backwards compatible, but as I understand it it isn't really relevant for publishing the marker artifact, right?

fourlastor commented 5 months ago

I think the extra config wasn't needed in the end (the publish plugin is applied from publishing.gradle), sorry for the long wait!