Page 1 of 1
Spring depends on Java?
Posted: 01 Nov 2007, 18:58
by HAARP
Code: Select all
# emerge -vDNp spring
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild N ] app-portage/portage-utils-0.1.28 78 kB
[ebuild N ] media-libs/glew-1.3.5 382 kB
[ebuild N ] dev-util/scons-0.97 430 kB
[ebuild N ] media-libs/devil-1.6.7-r2 USE="X gif jpeg opengl png sdl xpm -allegro -mng -tiff" 2,943 kB
[ebuild N ] dev-java/java-config-wrapper-0.13 7 kB
[ebuild N ] dev-java/java-config-2.0.33-r1 25 kB
[ebuild N ] dev-java/java-config-1.3.7 15 kB
[ebuild N ] dev-java/sun-jdk-1.6.0.03 USE="X alsa -doc -examples -jce -nsplugin" 67,006 kB
[ebuild N ] virtual/jdk-1.6.0 0 kB
[ebuild N ] games-strategy/spring-0.75_p2 USE="-debug" 4,009 kB [1]
Is that Java stuff really all necessary? Because I'm not really that keen on emerging Java...
Posted: 01 Nov 2007, 19:07
by AF
Its used for the java bindings in unitsync.so
Aside from that javas great, people just happen to like writing bad programs in it.
Posted: 01 Nov 2007, 19:28
by HAARP
AF wrote:Its used for the java bindings in unitsync.so
So in short, it's essential to compile Spring? Damn.
Posted: 01 Nov 2007, 19:38
by Kloot
No, you can compile Spring and unitsync
just fine without having a JDK installed, but
it requires hacking the buildsystem a bit. In
rts/build/scons/config.py, comment out the
lines:
and
by putting a '#' in front of them. Then, in
tools/unitsync/javabind.cpp, place this
line between the last DLL_EXPORT and
the "#include <jni.h>" directive:
and all the way down at the bottom of
the file, insert an extra
This will make scons oblivious to Java, and
build unitsync without JNI bindings.
Posted: 01 Nov 2007, 19:41
by semi
The spring ebuild depends on virtual/jdk so you can emerge some other package that provides it.
Posted: 01 Nov 2007, 19:43
by HAARP
Thanks! Will this break anything, like online play?
semi wrote:The spring ebuild depends on virtual/jdk so you can emerge some other package that provides it.
Sorry, I don't understand this sentence..
Posted: 01 Nov 2007, 19:50
by Tobi
HAARP wrote:Thanks! Will this break anything, like online play?
Can't use AFLobby then, unless you replace your unitsync.so with a version compiled with Java (java libraries are not needed, just header files).
Posted: 01 Nov 2007, 19:51
by Kloot
Nope, it won't break anything except
AFLobby (which depends on the JNI
parts of unitsync, but I assume you
don't use it).
e: what Tobi said
Posted: 01 Nov 2007, 20:10
by HAARP
Excellent, thanks.
Sorry AF, it's not that I find Java bad or something, it's just that I don't want 80MB of libs just to compile a bit of Java support into Spring...
Posted: 01 Nov 2007, 20:31
by AF
You dont need 80MB of libs you just need a 200kb jni.h and the accompanying 20kb linux specific file.
Perhaps we could look into bundling the 2 headers with the spring source/svn? Where exactly would they go in the spring folder structure?
Posted: 01 Nov 2007, 20:38
by Tobi
Ya was just thinking about that, could put them in tools/unitsync/include, that seems like the most logical location given that Spring does not need them at all.
That is, if they are licensed under GPL or a GPL compatible license.
Posted: 01 Nov 2007, 21:27
by HAARP
I can't even get to compiling. I don't know however if this is related to me removing Java. Can anyone help?
http://pastebin.ca/757999
edit: screw this, you're right. Using pastebin now.
Posted: 01 Nov 2007, 21:28
by Relative
You could of used a paste bin :/
Posted: 01 Nov 2007, 21:31
by Tobi
boost-thread is apparently missing in the dependencies of the ebuild.
Posted: 01 Nov 2007, 21:59
by HAARP
Tobi wrote:boost-thread is apparently missing in the dependencies of the ebuild.
I already had
dev-libs/boost installed. The problem seems to be that the ebuild doesn't check whether it's compiled with the "
threads" useflag. I added that flag manually and recompiled
boost, which provided me with
boost_thread - exactly what Spring needed.
Compiling now.
Posted: 01 Nov 2007, 23:25
by semi
http://trac.springlobby.info/changeset/697
This should fix the issue. Just update your portage overlays with
"layman --sync ALL" and retry with emerge.
It should now work with both boost 1.33 (that needs to test that threads use flag is set) and boost 1.34 (which does not have that use flag at all).
If you have any other problems with the ebuilds, shout!
Posted: 01 Nov 2007, 23:46
by AF
Well Sun did put java under the gpl licence a month or two ago, hence the OpenJDK/Java 7 project
for example:
Big long link to file in openjdk svn