2014/1/7 Cedric BAIL <cedric.b...@free.fr> > On Tue, Jan 7, 2014 at 1:27 AM, Tom Hacohen <tom.haco...@samsung.com> > wrote: > > On 06/01/14 04:25, Cedric BAIL wrote: > >> As we move forward with Eo and Eolian, we will generate a part of our > >> code automatically at compile time (some .c and .h). We also by now > >> require a C++ compiler (for ephysics) and Lua for Edje. So I am > >> thinking it is starting to make sense to plan the generation of those > >> bindings at the compile time of EFL to, instead of relying on another > >> stage where will would generate those. > > > > I disagree. > > > > First of all that "another stage" is done by packagers, and since > > packagers will split those anyway (more work), it doesn't save anyone > > any work, but might actually increase the work for packagers (now having > > to remove the C++ libs and headers). > > There is no such think as a C++ library and I don't see why they would > specifically split away C++ header out of EFL devel package. You would > have to enlighten me on how you expect EFL to be packaged. I am > arguing that it is a bad idea to split EFL more than just a devel > package and the rest. > > >> Benefit would be that we do provide support for 3 languages out of the > >> box when you install the developers package of EFL. We are not adding > >> a new set of dependency as they are already in. Also we can just parse > >> Eolian file once and generate all output code at the same time which > >> will be more efficient and will generate bindings faster than if we > >> have to do that outside of EFL. > > > > This is not for free. >
Indeed is not for free, apart from the rough generation of the binding there are lots of collateral work to do for each lang: documentation, unittests, examples, etc Without counting the post maintenance: testing, helping users, writing tutorials, etc. IMO supporting lua just because we depend on it yet is quite crazy (and a huge work). Speaking about python: the generation step do not require nothing at all, If I understand correctly how eolian will work: Eolian will write all the Cython files more or less as they are now, thus also generating the setup.py script. The dependencies comes when you want to compile and install the generated bindings, at that point you will need the python dev package and cython installed. I'm right? is this the intended workflow? 1. eolian (when compiling efl) will generate the bindings source code 2. the user then go in the "py-binds" folder and run "python setup.py install" or we want the bindings to be installed automatically on "make install" ? The question is: eolian just generate or also install the bindings? For sure me and kuuko will work on the python side of eolian, so please think at it from the start, surly under an --enable-python-bindings flag, just provide us with an empty shell in eolian and soon we will start to work on. davemds If you think supporting more languages out of the > > box is needed and wanted, by all means, we should support python (our #1 > > used binding for the last few years, except for maybe JS at free.fr) and > > some others as well. If it's beneficial, we should do it. However, > > claiming it's "free and already easy" is just not true. The only valid > > point here is not requiring any deps (so they are "cheaper" to add), but > > following that logic, we could add the ruby-ffi bindings, which I don't > > think have any external deps as well, because hey, it's free. > > I would be surprised that ruby-ffi doesn't require some header at > least and the generated devel package would obviously be dependent on > ruby, so it would add a dependency. > > Now, I would have suggested adding python and js, if there was no > dependency added to EFL. That's not the case, so I am not going to ask > for them being generated there, but having more language supported by > EFL out of the box when we do require them anyway, is I think the > right move to follow. Especially when the maintenance cost is near > zero and will be better handled by having everyone taking of it than > only one or two guys on their spare time. > > > I hope you are joking about parsing eolian just once, because if you are > > not it would mean your plan on cramping the whole binding generation > > logic (for every language) into eolian which is completely unnecessary > > and messy. > > Are you kidding me ? Any proper design of such a generation tool would > be split into stage. A first stage will parse eolian file and generate > an AST. That AST will then be given to multiple backend that will > generate C headers and C files. Meaning from the beginning we need a > modular architecture where we have at least two backend. Also we want > to move to Eo2, so it require two additional module to handle that. At > this point writing another module for C++ header and another one for > Lua is not going to change things much. > They should be cleanly isolated in their own directory and just > read the Eolian structure that they are given to generate the file > they are asked to. On the long run, supporting a new language would > either require someone to write a full parser and the output logic or > just write a module. I guess writing just a module will be the way to > go. > absolutely agree with you on the design > This will have the added benefit of having one command line to > handle all backend, one parser to update when we add new feature to > our eo language and so on. It also reduce the need to make Eolian a > public supported API for some time as we would have a set of module > that would use it internaly for generating bindings. Basically, it is > the best course of action to have a reduced maintenance around Eo. So > I have no clue on how you planned to do it, but clearly it was a bad > idea since it wasn't modular nor reducing maintenance and cost of > adding new binding to it. > > > As for generation speed: I'd assume/hope scanning the whole > > eo files we have takes less than 1 second. 1 second in the compilation > > time is nothing, and definitely not worth the complexity. > > You basically moved the complexity to somewhere else and increased it > at the same time. Hopefully for you, you are not going to be the one > handling that increased complexity. > > >> There is yet no code to really show, except a few discussion on phab, > >> but they are clearly not ready for integration in our git. The reason > >> I am bringing it here, is just that Tom wanted a proper place to > >> troll^Wdiscuss the idea of generating bindings at the same time as we > >> do compile EFL. > > > > We are getting fat. We've gone too far. Every pet project someone has is > > now going into core. We ship by default a lot more things that we used > > to a while back, and our complexity keeps on growing thanks to "cool and > > almost free" things. > > Please define your metric of fat. Right now EFL 1.8 compile faster > than EFL 1.7, it use less RES and SHR memory than before and we are > also faster than before. So by which metric do we get "fat" and how > does it impact us. > > As for complexity increasing, that's life. EFL was not intended to > become a toolkit, but as more project use it, we are finding things > that are better integrated in EFL than duplicated and left to > application or outside of the project. We are making the logic of EFL > become more and more complex. Does Eo increase the complexity of EFL ? > Should we drop it then ? Does Edje increase the complexity of EFL ? > Should we drop it then ? Does Eet increase the complexity of EFL when > a few simple file would do the job ? Should we drop it then ? I can go > on, but everything that we have in EFL obviously increase the > complexity, but for a good reason providing out of the box something > that help developers to provide better application. > In that regard, a C++ and a Lua binding, do fall into the category > of let's improve what developers can do out of the box with EFL. And I > do maintain that the cost of maintenance and packaging will be lower > inside of EFL. > I do think that the goal of EFL is to make life of third party > developers easier, not more complex. There is a balance to be made on > when doing something is for the few or for a bigger crowd, but clearly > the number of potential developers using C++, Lua or writing bindings > for EFL is, I hope, for a bigger crowd. > > >> I am not putting Python or JS in this list as that would indeed > >> increase the number of dependencies to build EFL which we also don't > >> want to increase that much anymore. > > > > Again, why not ruby-ffi? If it was possible to include Python without > > increasing the dep list, would you be up for it? Why not include the > > python bindings with a configure flag (to make things easier)? > > I don't know about ruby-ffi. I may be wrong on that one, but wouldn't > it require any additional dependency for packager ? Anyway if what you > say is true and someone take care of adding the needed module to > generate it, I would agree to it being added. So obviously the answer > would be the same for Python. In general if no added dependencies, I > would agree about any language binding generator to become a module in > EFL tree. > -- > Cedric BAIL > > > ------------------------------------------------------------------------------ > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
