Because the merge of the caiinterface branch is near, I would like to know how we should handle the bindings (wrappers). Right now, hoijui has a C, a C++ and a 2 Java-bindings.

Now Agon has asked to merge his mono-wrapper. The question is, should we include all wrappers in the main repo?

I could basically think of 2 possibilities:
1. Include them all in spring-repo
pro: easy to do
con: repo will grow, the amount of wrappers might grow, need to merge every change from the forks

2. Submodules (git submodule)
pro: maintainers have full control over their submodule, spring repo will not grow because they are modular and optional
con: never done before, not as easy as 1

Some git submodule tutorial, to see how it works: http://git.or.cz/gitwiki/GitSubmoduleTutorial

Opinions? I would favour trying 2 first, we can still mergethem in the repo later

edit: bibim said I got something wrong, now waiting for him to make a diagramm to explain.

i am currently assembling a diagram to explain the code sturcture of the new C Interface. i suggest you all wait till you saw it, before thinking about this.
eta: very soon


no really, should come today

I'm not sure the increase in repo size is big enough to be noticeable. I'm not against trying submodules, but I'm +1 for inclusion in the engine repo anyway (as long as build is optional so I don't have to download epic amounts of dependencies.)

Here it is!


Repo size of the Interfaces:
C 26KB
Java 207KB + 1.5MB Java libs (*.jar files)

+1 for direct inclusion in main repo

An alternative Idea
We could try submodules for upcomming new AIs. Expecially non native AIs (eg. Java or Mono AIs) would be well suitet for this. Code-Wise, they will genereally be very loosly coupled to the engine. For example in the case of Java, they only need AIInterface.jar from the Java AI Interface.
This way, we would aquire practical knowledge about git submodules, and if we see that it would work well with interfaces aswell, we could still put them into such modules later.

An other thing to consider is, that small maintainance work on the interfaces can be done by all spriong devs, if they are in the mian repo, whereas we would have to rely on one or a few maintainers per AI Interface otherwise.

Edit:
for more diagramms concerning the workings of the itnerface, see:
viewtopic.php?p=328843#p328843

btw I'm -1 for having jars under version control.

1.5 mb seems a bit larg'ish, despite the fact there are ubuntu packages for it (also debian / gentoo, rpm's seems missing)

As discussed with Agon and Auswaschbar, the java libs will be moved to mingwlibs on windows, and i will write SCons and CMake find scripts to find them under POSIX. For this to work, i will need all possible paths (including filenames) to the *.jar 's from libjna and libvecmath when installed with your package manager, plus the .so from libjna.
so please donate some!
on Ubuntu it is:


i hope to be able to use regex to find them, so the version does not matter.

Gentoo:
/usr/share/vecmath/lib/vecmath.jar

No jna because gcc was not built with libffi.

those paths should be configurable, preferably during runtime, perhaps by an environment variable or a simple spring config var.

On thing I can't quite figure out. What is the bottom right box labeled AI/Interfaces/Java/..., that is autogenerated?

yes, it is auto generated (AWK scripts parsing the C interface and one of the generated .java files). They create a bunch of other .java files that create an OO layer over the basic Java wrapper.
The C interface uses a lot of IDs (unitId, groupId, weaponId, unitDefId, ...) plus, it has a flat hirarchy, obviously, as we cant have classes. the basic Java layer works just like that, it is a direct wrapper over the C interface. When you use this layer, you do only Java, and Jav ais OO only, as we know, ubt it just does not feel like OO. It is like a direct Java wrapper of OpenGL. Just one big class with a few hundred functions. The Java OO wrapper changes this: you should not have to use IDs, but you use the Unit, Weapon, UnitDef, etc. classes. Also, the callback, having function pointers like this in C:

looks like this in Java:

And like this in the Java OO wrapper: