On Wed, 22 Apr 2020 09:45:23 +0200 Marcel Hollerbach <[email protected]> said:
> > > On 4/21/20 7:16 PM, Carsten Haitzler (The Rasterman) wrote: > > On Tue, 21 Apr 2020 16:35:08 +0200 Marcel Hollerbach <[email protected]> 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 <[email protected]> > >>> 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.... and then you have a different build system that works differently doesn't produce packages or source tarballs the same way etc. etc. etc. so it's creating barrier of entry, more work for packagers and more resistance to distribution. > >>>> - .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 it's not complicated to you. it's not complicated to me. it is complicated to 99% of users who then have to clone another repo and read a different set of build instructions. look how people already struggle to read README and INSTALL files once for meson. now add a different build system in, a new set of fragmented instructions etc. etc. > 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 it matters as it applies to bindings. our merge of all the efl libs into efl really improved things a lot and negated the need for such workarounds like above. you're just saying you want one workaround instead of another. my experience tells me it will bitrot. it will increase friction - like packagers will be less likely to package it as they will not use that super repo or script most likely (i know not of a single debian/rpm/whatever pkg that uses easye17/efl etc.). > 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. the packages still have to be created and submitted to such repositories etc. it still will hurt for bisecting to find issues. maven/pip etc. only are half solutions because they install bindings and not the dependencies and efl itself is a large dep and it in turn has dependencies. these work great if there are no external deps - it's just like a new json parser in python or java or whatever. but i see an upside... it allows me to ignore languages i'm not interested and get rid of the noise. since i know they will bitrot i know the bindings will eventually die, i get rid of a worry in my life. :) it's a bit of "tongue in cheek", but i really do see this happening. i see the car going around the same block i've been around multiple times and your argument of "oh but this block is special. it's different". i've heard it before. my experience tells me that is not the case. my gut tells me strongly it is not. every time i've not listened to my gut, i've made mistakes. i can point to many of them. every time i have said yes to something i truly believe i should say no to just to make someone happy, it has ended up in badness and things i regret years later. you are asking specifically about keeping jeff (i much prefer calling him jeff as it sounds nice :)) out of efl and i can't force you to move it into efl. i won't force you. i am giving my honest feedback from decades of experience and many mistakes i have made as well as things i have seen go right. you are not forced to follow that. :) as for removing bindings from the efl tree ... it'd make it leaner. i like that.. lua can't go out as it is required by our build and tooling like doc generation and really we want to use the lua bindings in efl anyway, but the rest can go out. it would be unwise. i'd welcome python bindings into the efl tree with open arms when they get to being totally eo based. so it'd hurt bindings that are out of tree in terms of exposure, ease of install, packaging etc. ... but it'd clean up the efl tree a bit. :) > >> 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 > >> [email protected] > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >> > > > > > > > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - [email protected] _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
