On Mon, Jan 6, 2014 at 2:27 PM, Tom Hacohen <tom.haco...@samsung.com> wrote: > 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.
+1 for all your reasons below. > > 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 -- Gustavo Sverzut Barbieri -------------------------------------- Mobile: +55 (19) 9225-2202 Contact: http://www.gustavobarbieri.com.br/contact ------------------------------------------------------------------------------ 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
