Hey Guys,
Since there was some confusion and the SDK was un-buildable, I created a workaround to this since it doesn’t seem like the Server is going back up so soon.
The SDK now has a build_engine.sh Script for Linux/Mac only which checks out the engine sourcecode to engine, applies the patch from the patches directory (Pending PR #501), compiles the engine and deploys it to your local maven repository.
Then the SDK has the new mavenLocal() Repo which picks them from there.
There is no Windows support since it’s missing tools like patch, mvn (maven) and git. If you have some linux build environment set up you can, of course, launch it from there.
These are not Linux specific. Nor can you expect them to be there by default… so I would think they are in the same boat as windows as far as “make sure you’ve installed these tools”.
What is it that you have to patch?
Are you attempting to build the SDK against engine’s master or can you mostly just pull the dependencies from jcenter like everyone else? (minus the few jars that aren’t there… or is that the issue?)
With the difference that on Linux it’s just one package manager call away and under windows at least git used to need a linux environment, so it’s bit more challenging to set up (and then you’re in a bash env again).
This tool does nothing you couldn’t do by hand, though, so you can run it anywhere.
I have to patch the #501, since it destroyed every animated j3o when opened in the sdk.
Other than that we need the master since we need some other crucial patches (some blender importer change which used to spam the log until the SDK locked up) plus those few jars.
jCenter doesn’t support Snapshots, I guess?
Maybe we want another repo for that in the long run.
You got me wrong:
By master I meant the latest commit of v3.1 branch.
Nope I didn’t open a PR for 3.1, but since the one for master didn’t get applied anyway (and was from back in the days were there was no 3.2), I didn’t reopen another one so far.
And [quote=“sailsman63, post:6, topic:36200”]
Git works natively on Windows, directly in the standard Windows shell. So does Maven, which runs off the system Java installation.
[/quote]
Didn’t know that, at least source tree did create some bash environment I guess. But good to know, then a brave windows user could simply change the ./gradlew to gradlew.bat
The gradle wrapper plugin should have generated both… so I assume you mean that they just type gradlew (which will automatically resolve to the .bat file on windows)
Yes and no: To call subtasks I relied on calling those commands (since I didn’t want to include them directly).
But I’ve learned now that there is a GradleBuildTask thingy to use, so I’ll do that asap.