Hi!
On 4/21/20 12:45 PM, Carsten Haitzler (The Rasterman) wrote:
On Tue, 21 Apr 2020 11:31:11 +0200 Marcel Hollerbach <m...@bu5hm4n.de> said:
Hi,
This is a long mail, containing first an announcement and then a suggestion.
The announcement:
The last two weeks I have been working on a project called jefl, as the
name might suggest it, these are java bindings, fully generated out of
.eo files.
java? my nemesis! my adversary... the dr. evil of languages! :)
You might now ask why I was choosing Java instead of something else.
Java was chosen because it's a language where we are not having working
bindings at all. I did not want to have any competition with any
existing project, hence I choose a language that is not there yet.
Another reason why I chose java is that we also need (and have) JNI
bindings, this is nice, because bindings for clojure, groovy or scala
can be built on that as well, with very little time invest, as the more
complex part is already done in the jni part.
For anyone who doesn't know what jni is: When writing bindings c <->
java, you need to have some "glue" that is handling the calling of your
native c code out of the java vm context, and the other way around. This
"glue-layer" is called Java Native Interface (JNI).
As of right now, you can build with jefl little applications, as a
example: https://phab.enlightenment.org/F3868538. The whole thing then
looks like
https://www.enlightenment.org/ss/display.php?image=e-5e9eb1fa897593.48620171.jpg.
I have *not* written the bindings for eina to java yet, so if you use a
API call that returns a iterator, list, array, slice, etc. You will
simply get a empty object returned, where you cannot do anything with
it. This of course will not stay like that, my primary focus was just on
the generation of java API for now.
To test this whole thing:
- Configure your EFL to install eo files (meson configure
-Dinstall-eo-files=true)
- You need EFL with the branch devs/bu5hm4n/eo_file_updates
After the 1.24 release this whole branch will be merged to EFL.
- Install "ant" on your system
- Clone, build, and install
https://git.enlightenment.org/devs/bu5hm4n/jefl.git/
- The previous steps will have created "jefl.jar" in ./build/java which
now can be included in your IDE of choice, where you can write your jefl
app.
If you just want to have a look at the .java files, I uploaded a
snapshot of the .java files to https://phab.enlightenment.org/F3868537.
I am happy over any comment on the .java files, it has been quite some
time since I wrote java, and I might be a bit outdated to "how" you do
things these days, so any comment there is welcome :)
And now the suggestion:
Jefl is meant to be built out of the EFL tree (but maybe in a single
repository), and I think we should do that for more (if not all)
bindings, which are not required in EFL itself (like lua, for bob).
Reasons for this:
- Efl uses meson which is nice for c, however, integrating different
languages with it *into* EFL is highly complex, and we have seen for C#
that this is ending up, simply proxying a native buildtool for the
language. Which however just raises the complexity of the EFL build itself
- Due to how meson is used in EFL for bindings, the set of generated
files does not follow the structure which is recommended / required for
the language the bindings are generated for. As an example: a class
named "efl.gfx.Entity" in java must be placed in the directory
efl/gfx/Entity.java this cannot be realized with the meson stuff we have
in place, as this rule for placement is not the same for every file we
have, *and* it would require scripting to get the right position, which
makes the whole build process *again* more complex.
the code generator could generate the dummy output meson expects as well as the
java standard path.
Mhm, no, that does not work. The meson files have to be ready at
configure time, which is when we *declare* the generator, but not run it.
- .eo files work in a way where we can specify a class and a struct in a
single file, in java for example, a struct is complied into a class, as
well as a class. But every class which is public, do require its own
file. We cannot detect that at configure-time in meson, hence this would
also not work.
- The problem of having these repositories bitrot is different. We could
have somewhere a .eo file, which contains all possible built-in types,
all possible structures and @by_ref calls etc.. Additionally, each
generator should escape all keywords in a language. If we have that, it
should be quite hard to break bindings from EFL itself. Additionally, to
get an overview of *what* broke bindings, we can have a travis job that
is simply pulling in all bindings repositories and building them (once a
day or so).
To give you an overview to how this works in jefl: at configure time,
meson declares the generator, the generator has 3 outputs, a .c file
(the jni stuff), a build.xml (the build manifest for ant), and a
dependency file. The java files themselves are not known to meson at any
time. Additionally, a custom target is defined which simply calls "ant"
after the java files are generated. The files to generate .java files
for, are loaded from the eolian directory on your system. This way we
*never* have to worry about the placement of files in meson at all, and
all this complexity is removed.
So, what do you think about moving the bindings outside of the EFL repo?
bit.rot. there is far more than just having th types and use cases
still work. experience tells me that all the enthusiasm for splitting apart...
it will bitrot. it'll make it harder to get packaged and distributed. it'll
make it harder for people to find and build themselves. experience tells me
"no" to splitting. unless of course it's a sly way of getting rid of functional
and actually used bindings by not actually saying you're getting rid of them but
spinning it a positive as a split then watching it die off then being able to
not look bad for having killed them... :)
The mainreason bindings out of tree do look abandoned, is that they did
not keep up with adding APIs which got added (python is there a example
of actaully keeping up). The situation with automatic bindings is
different, the new APIs come there automatically by rerunning it, this
factor of bitrot is not existing there.
I also do not really see them simply put away into a totally different
git repository, i see them in a different core repository, simply picked
up by CI and building them, like once a day.
The bitrot can be taken care of by the fact that we built it in CI.
I also consider the bit rot situation not any different when bindings
are in a different repository because:
- We usally simply introduce work arrounds in .eo files instead of
fixing the problem in the language generator
- We disabled examples that broke over time, we did not fix them
- Bindings that are not built on CI and are not enabled by default
bitrot exactly the same amount as something out of tree, looks at the js
bindings.
Considering this, and the fact how much easier it is writing generators
when having this out of tree, i really see no benefit in having them
intree. And the mainfactor against bitrot (CI) can also be applied to a
external repository.
i have been down the path of split and merge and split and merge over the
decades. multiple times. splitting creates problems. there needs to be an
overwhelming need to split to justify it. in this case there isn't imho.
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
