On 4/21/20 7:16 PM, Carsten Haitzler (The Rasterman) wrote:
On Tue, 21 Apr 2020 16:35:08 +0200 Marcel Hollerbach <m...@bu5hm4n.de> said:
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.
no no - not generate the meson files. we currently codegen bindings from eo
files. 1 eo file produces possible multiple .c/h and .hh or cs etc. files. so
when generating generate multiple outputs. some are just targets with the meson
directory tree namespace as meson wants,m but the others are a dir tree that a
java world expects and then of course wrap the jave compiler with a small
script to have it take a messon namespace style input but convert that to the
java tree format and the generated files are there waiting to build.
Then we are back at hacking something into the shape that it is somehow
working.
Which has downsides:
- Dependencies are going to be broken again like in .cs files right now.
- ninja / meson does not know of the generated files, hence they
cannot be installed
We can also again start to hack around these issues but that will not
bring us any benefit except bringing more and more complexity....
- .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.
no. this is not just bindings experience. it's libs going out of e to libs
(split) then multiple libs split, then finally merge them for sanity. it's over
the last 20+ years of this even long before efl.. and there are other factors
too. i've seen the pain of bisecting "where did this go wrong"" across multiple
repositories as opposed to one. i bisected long before git was a thing - in
svn. it's a reduced problem today as there re like 2 main components like e+
efl - the problem happened in one or the other. or rage+efl or
terminology+efl .. or just efl itself which is easier. the merge of efl
brought and end to the nightmare of that "where is the problem". splitting makes
it worse again. if it's worked on by the same people and released together it
should be together unless there is a huge reason to split. efl vs is a huge
reason. one is an app, one a toolkit to make apps of which e is one (the main
one efl exists for). it's a split that is justified. i have spent decades
watching users struggle to build just efl then e.. only 2 things. it was much
worse when efl was split. having to tell people build orders and write scripts
for them. i've seen people complain many many may times of ""omg its so
bloated. so many packages to install" and that vanishes when its one big
package. i know it's stupid - but it's how the world works unfortunately.
splitting creates friction. lots of it. so much so that at times i've even
considered merging efl and e together- you install e and get efl. consider e
like elementary_test ... it's a full wm/desktop that comes along for the ride.
the problems continue to this day due to the split. dependencies outside of efl
continues to be friction to the point where if i could go back in time, i'd
never link to deps ever again. i'd write everything to dlopen deps and include
copies of the headers of those deps in the efl tree. dependencies being split
out and having to tell people to install dev/devel pkgs and so on for 1000+
distros out there jus makes me want to try and nuke the pain. the pain just
goes on for year after year after year with people far less capable technically
experiencing the most of it. every bone in my body tells me to learn from my
lessons and not agree to something i know goes backwards in the above world. :(
I never said, that your experience is only bindings, i said that this
here is about bindings.
And whatever you describe in the paragraph above is nice and all, but
absolutely not relevant to the situation we have here. This is about
bindings. Simply said, a bunch of files that get generated from
something efl installs. You do not really need dependencies outside efl.
I understand that it might be a pain to install efl, however, installing
a single repository that does not have any dependency beside efl, does
not really sound too complicated, i do not buy that this is a
dealbreaker. And even with that, i am not so sure right now, if a user
really should need to install it by hand, or fallback to solutions like
maven central, pip, etc.. Additionally, if a deployment of efl+e is that
hard why don't we have a single repository "suite.git" that contains efl
& e as submodules + a script handling all that for you (Brian morluxus
had there something called easy efl which is exactly made for that
purpose :)) ? Anyways, that is totally offtopic and does not really
matter for this thread here: Matter here is more to seperate the
bindings from efl itself, to improve the development process, because
then, we do not run into situations like D11742 or D11741 or D11734 or
https://git.enlightenment.org/core/efl.git/commit/?id=eb23ead06403e578383c5807f2a83b90c372e05d.
The pressure for something to break is then on the bindings, and not on
efl itself.
Installation and usage of a set of bindings can also happen in java via
maven in python via pip, this way, the distribution problem is then
solved in a language native way, and efl-bindings themselves are not
involved at all.
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
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
