Hey Guys,
We are unable to release new SDK Versions at the moment because we always exceed the travis execution time (a bit more than an hour I guess), because we build the engine ourself, download all the various jdks, repackage them and then (which takes the most time): Building the installers with compressed files for 6 OS.
What takes the most time is essentially the last part and removing OS’ would speed up multiple things (i.e. no seperate blender, no seperate jdk, no packing all the files), so my plan is to remove linux-x86 and probably windows-x86.
For Linux I am kinda certain but I don’t know how many windows users actively still have 32bit? At work they just deprecated the last x86 Laptop and I think that GameDev Machines should at least have some RAM and a relatively new OS, but I don’t know.
I don’t know if we couldn’t bypass this thing using the build matrix to build in multiple tasks, but I guess that only works when you switch used jdk’s in travis?
Seems like a good idea.
I don’t think any of our target groups are still using x86 only anyway.
It also seems unlikekly that you’re on a 32-bit machine for gamedev.
I have a 64 bit machine that is running 32 bit windows because that’s what I had.
Anyway, it seems like removing the OS is just a bandaid on the real problem. Wouldn’t it be better to split the build up into separate parts so that travis will be happy? Though I guess there is no easy way to communicate between jobs.
Does the SDK build its own engine or use the jars already built in the engine release? (The former is probably better, by the way, for a few reasons.)
Can we at least keep it an option to compile to x86? say, if your building the IDE or your games? I really like the fact I can use jME on Windows 2000 (I’m not joking, you can) even though it’s an outdated (as all heck) OS. I don’t know, I like the backward-compatibility even though no-one uses it.
Does Java 8 even run? Does it support OpenGL 2 hardware? Oh my… not to mention that it become a spambot the istant it connects on the internet… giggles!
And do you know if the deployment works from multiple instances? (As in they get merged instead of seperate release tags)?
While this is true we reach travis limits quite often (e.g. I needed to remove the engine source after I’ve built artifacts or else we’d reach the disk space threshold) and discarding an OS actually improves all of that including it reduces the build time of more than an hour.
I’ll try to fix the real issue when I have the time, though, that indeed might be better.
Btw: During the some user tests I discovered somebody donwloaded the x86 version thinking it was 64bits and a 64bit machine won’t complain about that so maybe we have some of these too (Because I can’t believe those are twice as many as mac users)
It does but it is also a source of never ending pain because the engine version names get screwed up depending on the tag and nearly every second build problem with the sdk is the user not building the engine first.
To clarify that: I was only talking about the SDK’s .exe and it’s bundled jdk/blender. You can always build your game for every version (it is java after all ) and even have the sdk bundle the jre for 32bits. It is only about your machine and yeah you could always manually build that as well if there was demand.
If JME works on W2k then LWJGL does a good job, I was expecting openGL to require XP or even Java. It is not as bad as DirectX of course, but I guess at least the Scene Explorer won’t work.
Btw: why no build slave running MS DOS and Gradle? Minimum OS Overhead
nah dos has to low memory, but yeah I would say lets drop some offical released version, they can still be build privatly and will still work. This seems like the best compromise of time spend/effect for the moment.
Like at the day job when someone thinks “We don’t have time to fix our build right now… so we’ll sit through 15 minute compiles and perform these 4 extra steps every time.” It adds up over time… really fast in fact.
Given that it seems to take a long time to run a build for just a simple config change and check, someone should really (sooner rather than later) look at refactoring the SDK build process to split it up somehow. a) we are less likely to have the “oh, we’ve gotten too big again which OS do we cut this time?” issues, b) it might make testing one config change a lot easier since you’d only have to rerun that part of the build.
This. I’ve seen it happen. Some people in java-land are so used to thinking cross-platform bytecode that they don’t even consider that many applications have native dependencies that are sensitive to processor architecture.
That, and I’ve been surprised by the occasional post on this forum by someone who doesn’t seem to even have any idea what the difference between 32-bit and 64-bit is.
Sure, Java 8 can’t be installed but if you used the jME installer (which installs it’s own version of java anyways) it works just fine, however this was back in 3.0, im not sure that works with the snapshots currently.
The tags will be the same (it’s multiple builds for the same Git reference), but I don’t know what happens when Travis attempts to make a GitHub release with a tag that already has a release associated with it.
) and even have the sdk bundle the jre for 32bits. It is only about your machine and yeah you could always manually build that as well if there was demand.