On 06/01/14 04:25, Cedric BAIL wrote: > Hello, > > 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). > > 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 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. 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. > > 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. > > 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)? -- Tom. ------------------------------------------------------------------------------ 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
