LWJGL Forum

I am working on adding a binding to LWJGL3 that could be useful for development of games.

I have been converting the header file to the Kotlan stuff based on the GLFW files, so far I don't have errors and I think I understand the structure of the enums and defines, my current problem is that when I test built it to check the Java output my binding was not in the release.

What did I do wrong? I added my files in templates/src/main/kotlin/org/lwjgl/library/libraryTypes.kt and templates/src/main/kotlin/org/lwjgl/library/templates/library.kt.

(also to the mods, sorry for making a couple posts so close. Figured these where different enough to warrant that)

I've managed to get it to build to a degree by adding the library to /config/build-bindings.xml, looks like I probably need to add it to the other platform ones as well.

Hey gudenau,

See this commit (https://github.com/LWJGL/lwjgl3/commit/b91b339fcd988322c581332611becd75f484d8b4) of the recently added rpmalloc bindings as an example. These are the non-obvious places where changes need to happen:

- /build.xml
- /build.gradle (missing in the above commit, added with this one (https://github.com/LWJGL/lwjgl3/commit/864d23393ebfee8b76aec9b43ed41e17d6a499b8))
- /config/build-bindings.xml
- /config/linux/build.xml
- /config/macos/build.xml
- /config/windows/build.xml
- /modules/generator/src/main/kotlin/org/lwjgl/generator/Generator.kt

Quote from: spasi on August 22, 2017, 09:57:30
Hey gudenau,

See this commit (https://github.com/LWJGL/lwjgl3/commit/b91b339fcd988322c581332611becd75f484d8b4) of the recently added rpmalloc bindings as an example. These are the non-obvious places where changes need to happen:

- /build.xml
- /build.gradle (missing in the above commit, added with this one (https://github.com/LWJGL/lwjgl3/commit/864d23393ebfee8b76aec9b43ed41e17d6a499b8))
- /config/build-bindings.xml
- /config/linux/build.xml
- /config/macos/build.xml
- /config/windows/build.xml
- /modules/generator/src/main/kotlin/org/lwjgl/generator/Generator.kt

I found those using grep, any way this could be streamlined any more?

Quote from: gudenau on August 22, 2017, 19:48:10any way this could be streamlined any more?

It's probably going to be simpler/cleaner when we port the Ant build to Gradle/Kotlin.

Now I have another issue, there is a recursive definition in a header.

Basically this:
C:

struct structure;

typedef void (*callbackMethod)(struct structure *data);

struct structure{
    callbackMethod callback;
}

Kotlin:

var structure = struct(
    LIBRARY_PACKAGE,
    "structure"
){
    callback.member("callback", "")
}

var callback = "callback".callback(
    LIBRARY_PACKAGE, void,
    "callback", "",
    structure.p.IN("data", "")
)


How do I resolve this? It says to define types explicitly and I am not sure what that means, I know nothing about Kotlin.

This happens often with structs that are defined in a linked-list manner. To break the recursion, you define a struct type without a body. Everything should be in the same order as the C definitions:

var structure_p = struct(LIBRARY_PACKAGE, "structure").p // declare the struct type (as a pointer to a yet undefined struct)

var callback = "callback".callback(
    LIBRARY_PACKAGE, void,
    "callback", "",

    structure_p.IN("data", "")
)

var structure = struct(LIBRARY_PACKAGE, "structure") { // define the struct type
    callback.member("callback", "")
}

Quote from: spasi on October 02, 2017, 06:42:10
This happens often with structs that are defined in a linked-list manner. To break the recursion, you define a struct type without a body. Everything should be in the same order as the C definitions:

Code Select Expand

var structure_p = struct(LIBRARY_PACKAGE, "structure").p // declare the struct type (as a pointer to a yet undefined struct)

var callback = "callback".callback(
    LIBRARY_PACKAGE, void,
    "callback", "",

    structure_p.IN("data", "")
)

var structure = struct(LIBRARY_PACKAGE, "structure") { // define the struct type
    callback.member("callback", "")
}

Thanks!

Sorry for being such an idiot with this stuff. :-/

Quote from: gudenau on October 02, 2017, 15:47:28Sorry for being such an idiot with this stuff. :-/

It's OK, the template DSL is anything but friendly. It's the reason very few people have been able to make binding contributions.

Next issue that I have not found a fix for:

There is a function that has a return type of struct strucutre**`, a null terminated array of structs. How can I make this work when the library allocates the memory for this? NullTerminated and PointerArray do not seem to work for this.

Quote from: gudenau on October 02, 2017, 18:04:10There is a function that has a return type of struct strucutre**`, a null terminated array of structs

That sounds odd. Isn't there an output parameter that returns the array size? Could you post more details about the function? (i.e. signature and documentation)

Quote from: spasi on October 02, 2017, 19:20:34

Quote from: gudenau on October 02, 2017, 18:04:10There is a function that has a return type of struct strucutre**`, a null terminated array of structs

That sounds odd. Isn't there an output parameter that returns the array size? Could you post more details about the function? (i.e. signature and documentation)

I agree, it is quite odd as it goes. There is a free method that you need to call though, at least you can clean it up.

Definition in the headers:
const struct libusb_pollfd ** LIBUSB_CALL libusb_get_pollfds(libusb_context *ctx);

Then the documentation for the function:

Quote
const struct libusb_pollfd** libusb_get_pollfds   (   libusb_context *    ctx   )   
Retrieve a list of file descriptors that should be polled by your main loop as libusb event sources.

The returned list is NULL-terminated and should be freed with libusb_free_pollfds() when done. The actual list contents must not be touched.

As file descriptors are a Unix-specific concept, this function is not available on Windows and will always return NULL.

Parameters
ctx   the context to operate on, or NULL for the default context
Returns
a NULL-terminated list of libusb_pollfd structures
NULL on error
NULL on platforms where the functionality is not available

You could try something like this:

// replace struct libusb_pollfd** with an opaque pointer
const..opaque_p(
    "get_pollfds",
    "",

    libusb_context.p.IN("ctx", "")
)

// example usage:
LibUSBPollFD fd;
for (long pp = libusb_get_pollfds(ctx); (fd = LibUSBPollFD.create(memGetAddress(pp))) != null; pp += POINTER_SIZE) {
    // ...use file descriptor...
}

If this style occurs again, I'll try to add NullTerminated support to return values. The above would become:

PointerBuffer pp = libusb_get_pollfds(ctx);
for (int i = 0; i < pp.remaining(); i++) {
    LibUSBPollFD fd = LibUSBPollFD.create(pp.get(i));
    // ...use file descriptor...
}

Nice, I made it generate source files that break the java compiler with comments ending early. :-P

I presume I should use an opaque pointer for the structs that have no body in the headers?

Yes. Examples:

// C
typedef struct libusb_foo libusb_foo;
void func(libusb_foo *foo);
// Kotlin
val libusb_foo_p = "libusb_foo".p

// C
typedef struct libusb_foo *libusb_foo;
void func(libusb_foo foo);
// Kotlin
val libusb_foo = "libusb_foo".opaque_p

Quote from: spasi on October 03, 2017, 08:43:38
Yes. Examples:

Code Select Expand

// C
typedef struct libusb_foo libusb_foo;
void func(libusb_foo *foo);
// Kotlin
val libusb_foo = "libusb_foo".p

// C
typedef struct libusb_foo *libusb_foo;
void func(libusb_foo foo);
// Kotlin
val libusb_foo = "libusb_foo".opaque_p

Would the first example then be:

// C
void doAThing(libusb_thing* thing);

// Kotlin
void("doAThing", ""
   
    libusb_thing.IN("thing", "")
)
[code]

or

[code]
// C
void doAThing(libusb_thing* thing);

// Kotlin
void("doAThing", ""
   
    libusb_thing.p.IN("thing", "")
)
[code]

I am leaning towards the first, but I am unsure.

I've edited my previous reply, it should be:

val libusb_foo_p = "libusb_foo".p // note the extra _p

So, in your example:


// C
typedef struct libusb_thing libusb_thing;
void doAThing(libusb_thing* thing);

// Kotlin
val libusb_thing_p = "libusb_thing".p
void(
    "doAThing",
    "",

    libusb_thing_p.IN("thing", "")
)

So, yes, the first one, but with _p so that it's clear what's happening.

Quote from: spasi on October 03, 2017, 16:50:31
I've edited my previous reply, it should be:

Code Select Expand

val libusb_foo_p = "libusb_foo".p // note the extra _p

So, in your example:

Code Select Expand


// C
typedef struct libusb_thing libusb_thing;
void doAThing(libusb_thing* thing);

// Kotlin
val libusb_thing_p = "libusb_thing".p
void(
    "doAThing",
    "",

    libusb_thing_p.IN("thing", "")
)

So, yes, the first one, but with _p so that it's clear what's happening.

Fair enough, now to look at the other bindings and get the native stuff working.

Issue with the build process, it is attempting to grab a required dll from your server. Seeing as the binding is not done how can I tell it to not do that and maybe even grab it from a local source?

Setting/exporting LWJGL_BUILD_OFFLINE=true will make the build skip all downloads.

Okay, mostly done with this. Just need to make sure all the documentation is in there, compare the code styling I used to the repo, test all the stuff I can, and maybe make some basic tests and port the example code.

Probably a couple more days, everything is well documented and has links to everything else that is relevant.

Odd problem, checks are happening where they should not be for a function.

I have tried this:

    size_t(
        "libusb_get_device_list", "",

        optional..libusb_context_p.IN("ctx", ""),
        Check("1")..libusb_device_p.p.p.OUT("list", "")
    )


and this


    size_t(
        "libusb_get_device_list", "",

        nullable..libusb_context_p.IN("ctx", ""),
        Check("1")..libusb_device_p.p.p.OUT("list", "")
    )


A null ctx tells the library to use the default one.

nullable.. should remove the check.

edit: btw, you can do Check(1) instead of Check("1").

Quote from: spasi on October 04, 2017, 20:26:49
nullable.. should remove the check.

edit: btw, you can do Check(1) instead of Check("1").

I'll double check that I did not mess that up then, and I will change all of those Check statements.

Edit:
Seems that it was just me being stupid like normal. Go figure.

It has been a while, things came up and this ended up being forgotten for a while. My bad.

Now that I am trying to get the documentation fleshed out I am not seeing a way to add the return info to a method definition in the Kotlin files. Is this supported?

Edit:
While I am at it, is the See Also stuff supported?

The generator supports @return, @see and @since. You use Kotlin named parameters to specify them, for example:

int(
    "functionName",
    "javadoc",

    // vararg parameters
    int.IN("paramA", ""),
    float.IN("paramB", ""),
    // ...,

    // named parameters after varargs
    returnDoc = "an int",
    since = "version M.n",
    see = arrayOf("refA", "refB"/* , ... */)
)

Quote from: spasi on December 06, 2017, 08:38:39
The generator supports @return, @see and @since. You use Kotlin named parameters to specify them, for example:

Code Select Expand

int(
    "functionName",
    "javadoc",

    // vararg parameters
    int.IN("paramA", ""),
    float.IN("paramB", ""),
    // ...,

    // named parameters after varargs
    returnDoc = "an int",
    since = "version M.n",
    see = arrayOf("refA", "refB"/* , ... */)
)

Thanks, I went through all the decelerations and could not find those.

How about deprecation? There is a deprecated method in here that is superseded by something else.

I usually skip such functions. If we need it in the future for backwards compatibility, it can be added trivially.

Quote from: spasi on December 11, 2017, 23:19:29
I usually skip such functions. If we need it in the future for backwards compatibility, it can be added trivially.

Okay, good to know.

Sorry for being stupid again, but I can not seem to find where to put the DLLs for the Windows stuff when making a binding with the latest commits.

Also, how do I provide the DLLs for the bindings when I submit the PR?

Edit:
Can not manage to get the darn thing to build, says that it can not open standard include files. Primarily stdio.h.

I can not seem to figure out what I might have done to break that.

Quote from: gudenau on December 28, 2017, 01:29:53Also, how do I provide the DLLs for the bindings when I submit the PR?

LWJGL binary dependencies are built from source and uploaded to build.lwjgl.org. The build script then downloads the dependencies it needs. They are never committed to the repository, keeping it small in size. The binaries can also be validated and trusted by users: the source is available under the LWJGL-CI (https://github.com/LWJGL-CI?tab=repositories) account and we use Travis CI (https://travis-ci.org/LWJGL-CI/) and AppVeyor (https://ci.appveyor.com/project/LWJGL-CI/glfw) to build it.

Setting this up is not exactly simple, so I don't expect contributors to do it. But if you'd like to help, or are simply curious, the process would go like this:

- Fork libusb to your account.
- Go to Travis CI and enable CI for libusb.
- Go to AppVeyor and enable CI for libusb.
- Push a commit with .travis.yml and appveyor.yml (copy these from another LWJGL-CI project to get started - ignore the AWS stuff).
- Go to the previous step until the builds work.

I would then use your YAML scripts to do the same under LWJGL-CI + upload the binaries the build.lwjgl.org.

Alternatively, for simple projects that can be built trivially and are updated infrequently, you could embed the source code in LWJGL (see nanovg, stb, lmdb, etc). This has the drawback that upstream updates have to be committed manually to lwjgl3, but avoids the CI pain.

Quote from: gudenau on December 28, 2017, 01:29:53Can not manage to get the darn thing to build, says that it can not open standard include files. Primarily stdio.h.

I can not seem to figure out what I might have done to break that.

Need more information to be helpful. Push your work to an lwjgl3 fork and I can have a look.

Quote from: spasi on December 28, 2017, 11:21:42

Quote from: gudenau on December 28, 2017, 01:29:53Also, how do I provide the DLLs for the bindings when I submit the PR?

LWJGL binary dependencies are built from source and uploaded to build.lwjgl.org. The build script then downloads the dependencies it needs. They are never committed to the repository, keeping it small in size. The binaries can also be validated and trusted by users: the source is available under the LWJGL-CI (https://github.com/LWJGL-CI?tab=repositories) account and we use Travis CI (https://travis-ci.org/LWJGL-CI/) and AppVeyor (https://ci.appveyor.com/project/LWJGL-CI/glfw) to build it.

Setting this up is not exactly simple, so I don't expect contributors to do it. But if you'd like to help, or are simply curious, the process would go like this:

- Fork libusb to your account.
- Go to Travis CI and enable CI for libusb.
- Go to AppVeyor and enable CI for libusb.
- Push a commit with .travis.yml and appveyor.yml (copy these from another LWJGL-CI project to get started - ignore the AWS stuff).
- Go to the previous step until the builds work.

I would then use your YAML scripts to do the same under LWJGL-CI + upload the binaries the build.lwjgl.org.

Alternatively, for simple projects that can be built trivially and are updated infrequently, you could embed the source code in LWJGL (see nanovg, stb, lmdb, etc). This has the drawback that upstream updates have to be committed manually to lwjgl3, but avoids the CI pain.

Quote from: gudenau on December 28, 2017, 01:29:53Can not manage to get the darn thing to build, says that it can not open standard include files. Primarily stdio.h.

I can not seem to figure out what I might have done to break that.

Need more information to be helpful. Push your work to an lwjgl3 fork and I can have a look.

Yeah, I am using a much smaller library that I would also like to use for the first one so I can fix more mistakes in libUSB.

Here is what I currently have, and I probably screwed something up with git. (https://github.com/gudenau/lwjgl3/commit/68ffb25d2adbe97156feb0d588002536b62ae249)

OK, tried it. It doesn't build because the discord-rpc source is missing, only the header is there. Solutions:

- If you'd like to build discord-rpc as part of LWJGL, add its source under modules/core/src/main/c/discord and adjust the build scripts accordingly (you'll have to switch to C++ compilation).
- If you'd like to build discord-rpc externally as a shared library and use it from LWJGL, use the SimpleBinding that you have already defined (DISCORD_BINDING). The discord-rpc source code isn't required, not even the header. No native code will be generated either, everything will be done via JNI.java.

Btw, make sure the generated classes do not start with a lower-case letter (e.g. change the className parameter of callbacks).

Quote from: spasi on December 29, 2017, 19:52:40
OK, tried it. It doesn't build because the discord-rpc source is missing, only the header is there. Solutions:

- If you'd like to build discord-rpc as part of LWJGL, add its source under modules/core/src/main/c/discord and adjust the build scripts accordingly (you'll have to switch to C++ compilation).
- If you'd like to build discord-rpc externally as a shared library and use it from LWJGL, use the SimpleBinding that you have already defined (DISCORD_BINDING). The discord-rpc source code isn't required, not even the header. No native code will be generated either, everything will be done via JNI.java.

Btw, make sure the generated classes do not start with a lower-case letter (e.g. change the className parameter of callbacks).

Okay, it is just a RPC library that should not be updated often so compiling it with LWJGL might be a good idea.

How would I go about adding the sources into the repo for complication?

Simply copy them from discord-rpc/src/ to lwjgl3/modules/core/src/main/c/discord/.

More STD header issues.


[Compiler] C:\Program Files\Java\jdk1.8.0_144\include\jni.h(39): fatal error C1083: Cannot open include file: 'stdio.h': No such file or directory
[Compiler] c:\users\gudenau\desktop\lwjgl3\discord\modules\core\src\main\c\util\lz4\lz4.h(43): fatal error C1083: Cannot open include file: 'stddef.h': No such file or directory (compiling source file modules\core\src\main\c\util\lz4\lz4hc.c)
[Compiler] modules\core\src\main\c\util\lz4\lz4frame.c(52): fatal error C1083: Cannot open include file: 'stdlib.h': No such file or directory
[Compiler] modules\core\src\main\c\util\xxhash\xxhash.c(107): fatal error C1083: Cannot open include file: 'stdlib.h': No such file or directory
[Compiler] c:\users\gudenau\desktop\lwjgl3\discord\modules\core\src\main\c\util\lz4\lz4.h(43): fatal error C1083: Cannot open include file: 'stddef.h': No such file or directory (compiling source file modules\core\src\main\c\util\lz4\lz4.c)
[Compiler] C:\Program Files\Java\jdk1.8.0_144\include\jni.h(39): fatal error C1083: Cannot open include file: 'stdio.h': No such file or directory (compiling source file modules\core\src\generated\c\system\jawt\org_lwjgl_system_jawt_JAWTFunctions.c)
[Compiler] C:\Program Files\Java\jdk1.8.0_144\include\jni.h(39): fatal error C1083: Cannot open include file: 'stdio.h': No such file or directory (compiling source file modules\core\src\generated\c\system\dyncall\org_lwjgl_system_dyncall_DynCall.c)
[Compiler] C:\Program Files\Java\jdk1.8.0_144\include\jni.h(39): fatal error C1083: Cannot open include file: 'stdio.h': No such file or directory (compiling source file modules\core\src\generated\c\system\dyncall\org_lwjgl_system_dyncall_DynLoad.c)
[Compiler] C:\Program Files\Java\jdk1.8.0_144\include\jni.h(39): fatal error C1083: Cannot open include file: 'stdio.h': No such file or directory (compiling source file modules\core\src\generated\c\system\dyncall\org_lwjgl_system_dyncall_DynCallback.c)
[Compiler] modules\core\src\main\c\util\lmdb\mdb.c(42): fatal error C1083: Cannot open include file: 'malloc.h': No such file or directory


Sounds like the msvc environment is not set up correctly. I use either "vcvarsall amd64" (for x64 builds) or "vcvarsall amd64_x86" (for x86 builds).

Quote from: spasi on December 31, 2017, 12:58:24
Sounds like the msvc environment is not set up correctly. I use either "vcvarsall amd64" (for x64 builds) or "vcvarsall amd64_x86" (for x86 builds).

I must be doing something very simple wrong....

This is on Windows, just using $ for the command.

$ "D:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Auxiliary\Build\vcvarsall.bat" amd64
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.4.5
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'
$ ant clean && ant compile-templates && ant generate && ant compile && ant compile-native
[snip]
init:

check-dependencies:

bindings:

generate:

-init-compile:

compile:

compile-native:

compile-native-platform:
    [mkdir] Created dir: C:\Users\gudenau\Desktop\LWJGL3\discord\bin\windows\x64\build
    [mkdir] Created dir: C:\Users\gudenau\Desktop\LWJGL3\discord\bin\windows\x64\lmdb
    [mkdir] Created dir: C:\Users\gudenau\Desktop\LWJGL3\discord\bin\windows\x64\lz4
    [mkdir] Created dir: C:\Users\gudenau\Desktop\LWJGL3\discord\bin\windows\x64\discord
    [mkdir] Created dir: C:\Users\gudenau\Desktop\LWJGL3\discord\bin\windows\x64\core
[Compiler] org_lwjgl_discord_discord.c
[Compiler] org_lwjgl_system_dyncall_DynCall.c
[Compiler] org_lwjgl_system_dyncall_DynCallback.c
[Compiler] org_lwjgl_system_dyncall_DynLoad.c
[Compiler] org_lwjgl_system_jawt_JAWTFunctions.c
[Compiler] lz4.c
[Compiler] lz4frame.c
[Compiler] lz4hc.c
[Compiler] xxhash.c
[Compiler] mdb.c
[Compiler] midl.c
[Compiler] C:\Program Files\Java\jdk1.8.0_144\include\jni.h(39): fatal error C1083: Cannot open include file: 'stdio.h': No such file or directory
[Compiler] C:\Program Files\Java\jdk1.8.0_144\include\jni.h(39): fatal error C1083: Cannot open include file: 'stdio.h': No such file or directory (compiling source file modules\core\src\generated\c\system\dyncall\org_lwjgl_system_dyncall_DynCallback.c)
[Compiler] C:\Program Files\Java\jdk1.8.0_144\include\jni.h(39): fatal error C1083: Cannot open include file: 'stdio.h': No such file or directory (compiling source file modules\core\src\generated\c\system\jawt\org_lwjgl_system_jawt_JAWTFunctions.c)
[Compiler] C:\Program Files\Java\jdk1.8.0_144\include\jni.h(39): fatal error C1083: Cannot open include file: 'stdio.h': No such file or directory (compiling source file modules\core\src\generated\c\system\dyncall\org_lwjgl_system_dyncall_DynCall.c)
[Compiler] C:\Program Files\Java\jdk1.8.0_144\include\jni.h(39): fatal error C1083: Cannot open include file: 'stdio.h': No such file or directory (compiling source file modules\core\src\generated\c\system\dyncall\org_lwjgl_system_dyncall_DynLoad.c)
[Compiler] org_lwjgl_system_jni_JNINativeInterface.c
[Compiler] org_lwjgl_system_libc_LibCErrno.c
[Compiler] org_lwjgl_system_libc_LibCLocale.c
[Compiler] org_lwjgl_system_libc_LibCStdio.c
[Compiler] modules\core\src\main\c\util\xxhash\xxhash.c(107): fatal error C1083: Cannot open include file: 'stdlib.h': No such file or directory
[Compiler] modules\core\src\main\c\util\lmdb\mdb.c(42): fatal error C1083: Cannot open include file: 'malloc.h': No such file or directory
[Compiler] c:\users\gudenau\desktop\lwjgl3\discord\modules\core\src\main\c\util\lz4\lz4.h(43): fatal error C1083: Cannot open include file: 'stddef.h': No such file or directory (compiling source file modules\core\src\main\c\util\lz4\lz4hc.c)
[Compiler] modules\core\src\main\c\util\lmdb\midl.c(20): fatal error C1083: Cannot open include file: 'string.h': No such file or directory
[Compiler] c:\users\gudenau\desktop\lwjgl3\discord\modules\core\src\main\c\util\lz4\lz4.h(43): fatal error C1083: Cannot open include file: 'stddef.h': No such file or directory (compiling source file modules\core\src\main\c\util\lz4\lz4.c)
[Compiler] modules\core\src\main\c\util\lz4\lz4frame.c(52): fatal error C1083: Cannot open include file: 'stdlib.h': No such file or directory

BUILD FAILED
C:\Users\gudenau\Desktop\LWJGL3\discord\build.xml:405: The following error occurred while executing this line:
C:\Users\gudenau\Desktop\LWJGL3\discord\config\windows\build.xml:183: The following error occurred while executing this line:
C:\Users\gudenau\Desktop\LWJGL3\discord\config\windows\build.xml:185: The following error occurred while executing this line:
C:\Users\gudenau\Desktop\LWJGL3\discord\config\windows\build.xml:19: apply returned: 2

Total time: 1 second


Can't think of anything, except an issue with the Visual Studio installation. Make sure the VC++ toolset and the Windows 10 SDK for Desktop C++ are installed.

Quote from: spasi on January 01, 2018, 17:34:47
Can't think of anything, except an issue with the Visual Studio installation. Make sure the VC++ toolset and the Windows 10 SDK for Desktop C++ are installed.

Turns out that seems to have uninstalled itself at some point. Thanks for all the help.

Edit:
More of me being dumb, now there are unresolved symbols for the Discord functions. About to push the stuff to my repo.

Edit:
The commit. (https://github.com/gudenau/lwjgl3/commit/43cff9a8632cb0f4b1d0bf54d6fea7090b482f82)

Don't worry, I will squash this before I do a PR and clean things up.

You must pass the SimpleBinding to the Discord template, like so:

val discord = "Discord".nativeClass(DISCORD_PACKAGE, binding = DISCORD_BINDING)

Also remove the "discord-rpc.h" include and any changes you've made to the platform build.xml files.

Btw, it looks like you're trying the JNI.java + shared library approach, which is not what you said here:

Quote from: gudenau on December 29, 2017, 20:05:30Okay, it is just a RPC library that should not be updated often so compiling it with LWJGL might be a good idea.

How would I go about adding the sources into the repo for complication?

Quote from: spasi on January 02, 2018, 09:57:57
You must pass the SimpleBinding to the Discord template, like so:

Code Select Expand

val discord = "Discord".nativeClass(DISCORD_PACKAGE, binding = DISCORD_BINDING)

Also remove the "discord-rpc.h" include and any changes you've made to the platform build.xml files.

Btw, it looks like you're trying the JNI.java + shared library approach, which is not what you said here:

Quote from: gudenau on December 29, 2017, 20:05:30Okay, it is just a RPC library that should not be updated often so compiling it with LWJGL might be a good idea.

How would I go about adding the sources into the repo for complication?

The header is needed for the library to build, it uses the same one for the public and private code in this case.

I will mess around a bit and see if I can't get this to work.

Edit:
I don't think I messed with EGL at all?

BUILD FAILED
C:\Users\gudenau\Desktop\LWJGL3\discord\build.xml:1089: The following error occurred while executing this line:
C:\Users\gudenau\Desktop\LWJGL3\discord\build.xml:910: The following error occurred while executing this line:
C:\Users\gudenau\Desktop\LWJGL3\discord\build.xml:793: C:\Users\gudenau\Desktop\LWJGL3\discord\bin\MODULES\org.lwjgl.egl does not exist.


Not sure what the problem may be. Try a clean build (ant clean).

Quote from: spasi on January 11, 2018, 09:19:52
Not sure what the problem may be. Try a clean build (ant clean).

I always do, guess I will push and squash see if I changed that by mistake.

Edit:
Is my stuff just screwed up? (https://github.com/gudenau/lwjgl3/commit/9a44d8f4a0ebf409b6be6fbf3c4616179a98f393)

Edit 2:
Seems my environment was goofed up.
C:\Users\gudenau\Desktop\LWJGL3\discord\build.xml:1016: The JAVA8_HOME environment variable is not set.

Edit 3:
Setting `JAVA8_HOME` to `C:\Program Files\Java\jdk1.8.0_144` causes `compile-templates` to fail.