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. 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. 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
