Gradle build

[Arcnor]

Is this considered/going to be considered?

I think it's the fastest way of getting LWJGL3 to be used by other projects without the current LWJGL2 hassle of generating POMs separated from the main build. It can be used to compile without ant at all, or it can be mixed.

I started adding support and got the kotlin plugin to compile all the sources, but got confused about the Generator.kt

If you're not planning on adding this, please close as wont fix so I don't spend any more time on it :D

[Spasi]

Yes, building with gradle would be interesting. Let me know if you still have trouble with the Generator. If you got it to compile, then it's a simple Java application, see the "generate" Ant target.

[Arcnor]

Ok, I'll continue then :).

Yeah, I know it's just a program, but it was strange that the Kotlin code was compiled using a Java tool. I need to look a bit more into it.

Also, do you mind if I move the code around? For ease of integration with gradle, it will be nice to have a module per "unit", i.e. "core" for the core library, "templates" for the templates library, and "natives" for the native library (or maybe "natives-linux", "natives-macosx" and "natives-windows", I need to check what needs to be generated). That means the code for each module will be inside /src/main/[java|kotlin]

[Spasi]

I understand the src/main/java thing is the Maven convention (over configuration), but it's not really compatible with how this project is set up. Especially, if you consider the generated code that's written in a different folder hierarchy (and I'd like to keep it this way).

I believe you can break the convention and configure everything manually in Gradle.

[Arcnor]

Yeah, I can break the convention, although some things like the Kotlin plugin might not like it. Also, it will be way more verbose.

I'll try to see what I can do.

Also, if you change where the generated code goes, IDEA will pick that up automatically and will detect the code as generated. I like that, but this it's your project ;)

[Spasi]

Thanks, I didn't know that feature. I didn't have to move the generated code though, just marked the root as generated. Noticed that IDEA disables inspections for the generated classes, do you know if it affects anything else?

[Arcnor]

You can either mark it as generated all the time, or put it on target/generated. Then IDEA will mark it automatically.

It doesn't affect much, although if you try to modify a generated class, IDEA will warn you.

[Arcnor]

Ok, an update on this.

I've managed to compile everything, although hardcoding some paths for now to make it simpler. Also, I managed to do it moving the code around like I said before.

I'm now trying to convert my code to use your non standard paths. However, it seems that the Kotlin plugin chokes on that, it compiles the Kotlin code fine, except for Types.kt (that depends on Java code, PointBuffer, that's going to be compiled at the same time). When I move everything into src/main/java and src/main/kotlin (it compiles Kotlin and Java code separatedly) everything works again.

I'm going to continue trying to make it work, but if I can't, will you accept that module (src/templates) being converted to some more standard? I'll also ask on the Kotlin forums in case I'm doing something wrong.

[Spasi]

The PointerBuffer dependency is resolved with classpath += "src/templates" in config/Templates.ktm. You should make sure that kotlinc is configured with Templates.ktm, because in the future it will be used for filtering the supported bindings. You'll be able to do custom builds, for example without OpenCL or with only the core OpenGL functionality, filter out old/obsolete extensions, etc.

[Arcnor]

Ok, I'll try to use the Templates.ktm file, although so far no luck with that one. Also, what that script is doing can be done with Gradle as well, and using Gradle flavors it will be even more elegant. But I'll try to make it work.

[big-guy]

hey @Arcnor, have you done anything with this yet that's available publically?

[virtuoushub]

Hi @Arcnor , like @big-guy, I am wondering if you have any code for the Gradle build I can take a look at.

[Arcnor]

Hi,

Sorry, but I don't have anything on the intertubes yet. I got it to compile, more or less, but never got it to use that Templates.ktm file (asked in their forums about the .ktm file, but got no response other than "use the mechanism native to Gradle: https://devnet.jetbrains.com/message/5527371)

I really want this to get with some project of mine (or even LibGDX) sooner or later, so if you can help, that'd be great :)

I'll try uploading what I had as soon as I get the time.

[dhild]

@Arcnor I think I figured out the kotlin configuration; I ended up just adding 'config' as a source directory for the templates compile. https://github.com/dhild/lwjgl3/tree/gradle_project if anyone is interested. Currently the java & kotlin files compile (haven't verified that they're functionally identical), and I've started looking at using gradle's native compilation mechanisms. Still a work in progress, but might give @big-guy or @virtuoushub a reference.

[dhild]

I've spent a little more time figuring out the native compilation, and got it working on windows. Using entirely the gradle build for compilation, I was able to get the WGLDemo and UniformArrayDemo classes to run. Still remaining:

• Setting up the Linux build (I'll probably do this later)
• Setting up the Mac build (I can write the script, but I don't have a Mac to test with)
• Consolidating the existing config (there's a lot of "if windows ..." statements, this could be handled better)
• Extending with a few more tasks, etc. to fully replicate the ant scripts:
  • Javadoc needs some tweaking
  • Release task has not been started
  • demo task (or tasks) could be created
  • I'm still figuring out exactly how the generated & wiki pieces fit into the build / workflow

I'll keep updating the fork I made as I progress.

[octylFractal]

@dhild I've got a Mac.

[dhild]

@kenzierocks Cool - would you want to tackle adding it into what I have, or would you like me to get it started first?

[octylFractal]

I think I only have time to test right now, so you should probably get started.

[Arcnor]

@dhild if @kenzierocks doesn't have time to test it, I can also do it after you've submitted what you need to submit.

Awesome that you got this to work. I stopped at the native libraries compilation for lack of time.

[dhild]

@kenzierocks @Arcnor Sounds great. I've been doing a lot of gradle configuration at work lately so it flows pretty quickly for me. From the gradle docs, not too sure how the Mac config even works; it looks like it uses the Clang configurations, so it could be pretty easy after getting the linux build down.

[dhild]

Okay - haven't tried it out on my linux environment yet, but I have an initial configuration for mac & linux uploaded. There was one hiccup in the mac setup, some sort of config relating to the sysroot setting and another related to the version in use. I left those out for the moment, so you might have to manually set them up. I'm betting that gradle does some of that configuration for us, but I'd have to try it out to find out....

Look for the TODO statement in the build.gradle file to see what I'm talking about.

[Arcnor]

I did ./gradlew build and that didn't go well:

/tmp/lwjgl3@gradle_project✗✗✗✗✗✗% ./gradlew build
:compileTemplatesKotlin
:compileTemplatesJava
warning: [options] bootstrap class path not set in conjunction with -source 1.6
1 warning
:processTemplatesResources UP-TO-DATE
:templatesClasses
:compileKotlin
No Kotlin files found, skipping Kotlin compiler task
:generate
Exception in thread "main" java.lang.IllegalArgumentException: Invalid generation target path: /private/tmp/lwjgl3/generated
    at org.lwjgl.generator.GeneratorPackage$Generator$4582b1a4$main$validateDirectory$1.invoke(Generator.kt:37)
    at org.lwjgl.generator.GeneratorPackage$Generator$4582b1a4$main$validateDirectory$1.invoke(Generator.kt)
    at org.lwjgl.generator.GeneratorPackage$Generator$4582b1a4.main(Generator.kt:41)
    at org.lwjgl.generator.GeneratorPackage.main(Unknown Source)
:generate FAILED

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':generate'.
> Process 'command '/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/bin/java'' finished with non-zero exit value 1

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 36.119 secs

[octylFractal]

~~Your latest commit (878664b3e08d701ca63f946421a2f8210378afad) should use it.options, not options.~~

Never mind, I don't know what's failing it.

[Arcnor]

@kenzierocks you can add comments directly to commit lines if you like :smile:

[octylFractal]

I do know, it's just quicker for me to use what I've already got.

[dhild]

@kenzierocks Whoops. I've always just used the implicit reference to the delegate object though, mostly because I think it reads easier.

@Arcnor Okay, I'm guessing that the generate failed because that directory didn't exist. I added a quick fix to create the directories first. I'm a little nervous about that because of the symlinks in the original script (don't yet know about those), but it might fix it.

[Arcnor]

@dhild ok, that got me further. Now:

 warnings
:processResources UP-TO-DATE
:classes
:jar
:compileX64DebugLwjglSharedLibraryLwjglC
In file included from /private/tmp/lwjgl3/src/native/system/common_tools.c:5:
In file included from /private/tmp/lwjgl3/src/native/system/common_tools.h:26:
/Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/jre/../include/jni.h:45:10: fatal error: 'jni_md.h' file not found
#include "jni_md.h"
         ^
1 error generated.
:compileX64DebugLwjglSharedLibraryLwjglC FAILED

jni_md.h is on /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home/include/darwin/jni_md.h, not sure if you can automate that

[Arcnor]

Ok, commented too quickly. I edited build.gradle and added the include for /darwin, but now:

:compileX64DebugLwjglSharedLibraryLwjglC
/private/tmp/lwjgl3/src/native/system/org_lwjgl_system_MemoryUtil.c:24:19: fatal error: use of undeclared identifier 'intptr_t'
        return (jobject)(intptr_t)globalRef;
                         ^
1 error generated.
:compileX64DebugLwjglSharedLibraryLwjglC FAILED

[dhild]

@Arcnor That's weird. stdint.h should have intptr_t defined (or at least include its definition). Not sure where to go with that one.

https://github.com/LWJGL/lwjgl3/blob/master/src/native/system/macosx/MacOSXConfig.h#L7

[Arcnor]

If I add #include <stdint.h> at the top of the file, I get past that error, so it seems stdint.h is not being included...

[Arcnor]

Ok, found the problem. Your defines inside build.gradle should not include the initial D