we talked about both things for a while but now it is happening. As we are in flux between 3.0 stable and the next 3.1 release we use the opportunity and change a few more things around the engine.
We are in the process of moving our svn repository to GitHub, including the current stable branch. From now on all development will continue in GitHub. We will also move the project build to Gradle over the next days.
Sadly we had to abandon what was the “gradle-restructure” branch and will have to rebuild the gradle structure in GitHub. So the master branch will change a lot over the next few days, this will also mean that the SDK and a few other things like bullet will fail to build in the github master but this should be fixed over the next weeks.
The GitHub repo will by default point to the “3.0” branch, which contains the current 3.0 stable release with all fixes (3.0.5 atm). A last merge for 3.0.6 will be made in svn and then merged back to GitHub, any following updates to stable will be made from GitHub directly. This is because the stable updates are currently built from svn.
We hope to ultimately simplify the contribution process for jME3 as well as SDK plugins (some announcements to follow later) with this move to GitHub. The move to gradle should give us enough flexibility to simplify our quite extensive build process. It will also allow us to finally push maven artifacts from 3.1 on.
All commit access to svn has been revoked, sorry if you were in the process of writing up contributions against svn, please adapt them for the GitHub master branch and the gradle project or for the stable 3.0 branch. The coming weeks will probably be a bit of a bumpy road but you can all test out the cool features of GitHub to help us even out the kinks
Made a branch from master called “gradle” which has the new Gradle layout, the SDK build is not working yet and some native builds also need more work.
The issue with GitHubs history is that the GitHub web display doesn’t do a --follow, so it will only show the complete history of a file that is never moved. This means after the Gradle move GitHub will not show the full history anymore, you can see this in the “gradle” branch already. A full history can be seen using git command line or IDE tools however.
I added scripts that copy the engine jar files and create the needed XML files for the SDK build as well. Now the SDK gets built by the default setup as well. The gradle.properties file contains a flag that allows disabling the native and / or SDK builds if needed. Every contributor should of course still build with the SDK enabled to test the contributions for compatibility.
HOWTO
NetBeans 8.0 with Gradle plugin installed:
compile
Build the root “jmonkeyengine” project
run tests
Run the jme3-examples subproject
From command line:
Use “./gradlew build” and “./gradlew run” respectively
To edit the SDK, run the build once and open the “SDK” folder as a project in NetBeans 8.0
TODO
- finalize SDK updating
Currently its not copying over test sources and test-data
- fix SDK Android and iOS integration
Currently the needed libraries are not included in the SDK
finalize native builds for bullet and android
Everybody is welcome to fix the build scripts for the various platforms
finalize jME3 distribution creation
The ZIP distro should probably look similar to how it looked before
better check for changes for SDK rebuild
fix locations of native bullet files
The paths and names of the created native files changed, we have to adapt the native extraction code or the packaging
CAVEATS
SDK J2SE library entries have different names now
We’ll have to see how and if we keep backwards compatibility to old projects, probably via an importer. We plan to use gradle for user projects in the 3.1 release as well, so this might not be an issue as there will have to be an importer anyway.
the Engine jar distribution might not be compatible to your build setup
Hey, just wanting to help a bit with the native compiles of bullet, I simple checked it out and did gradle build
-> On my arch linux desktop it starts compiling a 32bit version (the os is 64) and then in the linking stops with this one here “/usr/bin/ld: cannot find -lgcc_s”
-> On my ubuntu server with jenkins it stops at build script evaluation with
Could not find method platforms() for arguments [build_4usphg6eomd5l0cpeoi2sjfqhr$_run_closure4_closure25@f882465] on project ‘:jme3-bullet-native’.
Am I’m on the correct branch? wich gradle version does it require? What is your build enviroment, so that I can maybe work out the problems from the difference.
@Empire Phoenix said:
Hey, just wanting to help a bit with the native compiles of bullet, I simple checked it out and did gradle build
-> On my arch linux desktop it starts compiling a 32bit version (the os is 64) and then in the linking stops with this one here “/usr/bin/ld: cannot find -lgcc_s”
-> On my ubuntu server with jenkins it stops way further with
-> Could not find method platforms() for arguments [build_4usphg6eomd5l0cpeoi2sjfqhr$_run_closure4_closure25@f882465] on project ‘:jme3-bullet-native’.
Am I’m on the correct branch? wich gradle version does it require? What is your build enviroment, so that I can maybe work out the problems from the difference.
You have an old version it seems, update your checkout. The correct branch is master now.
This specific error is a change in how gradle works (we use 1.11 now), I committed that change yesterday already. The build works in NetBeans 8 with gradle plugin as well as when using the gradle wrapper in the repository.
@Empire Phoenix said:
Hey, just wanting to help a bit with the native compiles of bullet, I simple checked it out and did gradle build
-> On my arch linux desktop it starts compiling a 32bit version (the os is 64) and then in the linking stops with this one here “/usr/bin/ld: cannot find -lgcc_s”
-> On my ubuntu server with jenkins it stops at build script evaluation with
Could not find method platforms() for arguments [build_4usphg6eomd5l0cpeoi2sjfqhr$_run_closure4_closure25@f882465] on project ‘:jme3-bullet-native’.
Am I’m on the correct branch? wich gradle version does it require? What is your build enviroment, so that I can maybe work out the problems from the difference.
In addition to what I said above, the build should be static but that doesn’t seem to work neither on OSX nor on Linux atm, if you remove the “static” parts in the build script it should work, but it will create a dynamic library. If you find settings to make it work static hit us, I’ll be looking into that whole shebang later.
@normen said:
In addition to what I said above, the build should be static but that doesn't seem to work neither on OSX nor on Linux atm, if you remove the "static" parts in the build script it should work, but it will create a dynamic library. If you find settings to make it work static hit us, I'll be looking into that whole shebang later.
I’d like to help with the bullet natives too. Before I removed the static stuff, I was stuck on the “-lgcc_s” problem. After removing the static stuff, the build said it completed. Did it just build the linux 64 version? In my /dist/opt/native-bullet directory, I only see a jme3-bullet.jar file. I would have thought a jme3-bullet-natives.jar would be created…? Just trying to get a feel of where things are so if I can help, I’m working on the right stuff…
@phr00t said:
I'd like to help with the bullet natives too. Before I removed the static stuff, I was stuck on the "-lgcc_s" problem. After removing the static stuff, the build said it completed. Did it just build the linux 64 version? In my /dist/opt/native-bullet directory, I only see a jme3-bullet.jar file. I would have thought a jme3-bullet-natives.jar would be created...? Just trying to get a feel of where things are so if I can help, I'm working on the right stuff...
Yes, you created a dynamic binary, the build products of the single subprojects are in their respective build folders. The copy in dist isn’t complete yet, its just there to create a similar distribution to before but will probably be removed.
Norman I’m playing a bit around with this currently, can you explain what the main difference between the static and not static build is?
Especially since for windows this does not seem to be used for the linker.
For all I see the result seems to be the necessary shared library with bullet in it. But then I’m not that deep into compiling with c / c++.
Hm after some more googleing how to mkae me a static gcc to compile against, I found this here.
Might this be relevant? (answer 1)
So if I understood correctly, wither abandom gcc as compiler or use shared.
Btw does osx use the gcc tollchain as well ? Could explain why it does not work there either.
@Empire Phoenix said:
Hm after some more googleing how to mkae me a static gcc to compile against, I found this here.
Might this be relevant? (answer 1)
http://stackoverflow.com/questions/3430400/linux-static-linking-is-dead
So if I understood correctly, wither abandom gcc as compiler or use shared.
Btw does osx use the gcc tollchain as well ? Could explain why it does not work there either.
Maybe the static-nss switch helps, idk. The main reason it doesn’t work is that its simply not configured yet. I’d expect to specify some library paths etc. anyway. As said, I didn’t look into this yet.
I just tried to attach the nexus plugin to the gradle build and the artifacts get uploaded nicely, with gradle taking care of the dependencies in the poms.
(missing are the two ogg-vorbis, stack-alloc, and jbullet, with the latter already mavenized it seems).
