Re: [E-devel] Time for efl-one
Hey, On 28/05/2020 15:17, Marcel Hollerbach wrote: > > Yeah, something like that was planned in the future, or building small > stubs without code that are just dragging in efl-one.so This way we do > not have to worry about platforms with problems about symlinks etc. > The problem is that the parts that are outside efl-one.so are still > linking to the smaller .so's and not to efl-one.so as that is a little > bit harder to realize, > and I first want to ensure that we *really* have a working efl-one.so > which totally works before investing more time into that. That actually makes so much more sense than my suggestion. :facepalm: > > The plan for getting everything on efl-one.so looks a little different > to me: > - Maybe move ecore_wayland and ecore_drm to a deprecated folder, that is > not handled as normal efl subproject anymore > - Move elua to lua bindings and or build it from there > - Find out what to do about ecore_avahi > > After that our normal code and build structure is in a state where > everything natively links to efl-one.so simply by calling subdir(...) in > another directory. We then can also automatically generate the > "declare_dependency" and "library" calls and shrink down the lib > meson.build files even more, which should simplify everything overall > quite a bit. > > But thats for the future, first lets find out how this works out :) Sure, just wanted to share my thoughts in case it would be too late later on, but it looks like you are already on it. :) > efl.pc is sadly not beta anymore, shipped, and used. > > I basically just really want to ensure that everyone understands that > this is not yet another subproject within efl, but the overall library > including a lot but not everything. And in the end, its just a name ... :) > Makes sense. :) Anyhow, again, great job! -- Tom ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Time for efl-one
On 27/05/2020 12:34, Marcel Hollerbach wrote: > Hi, > > after quite a big amount of work we have successfully landed this > morning a update to our build system which enables to build efl as a > single big .so instead of multiple seperated .so's. The layout is that > every single .so is merged into efl-one.so except: > - eolian: no normal app would benefit from it, and it would make our > build *a lot* more complex > - ecore_avahi: there is no real user for this within efl, in general i > dont think anyone is going to benefit from it > - efl_canvas_wl: This is also not beneficial to a standard efl application > - elua: This is only for bindings. > - ecore_drm / wayland : These are deprecated libs, not to confuse with > ecore_wl2 / ecore_drm2, which is included in efl-one > - exactness: Not useful for a normal efl app. > > To build efl-one you need to pass: "-Defl-one=true" to meson. After this > is done, additionally to all the smaller libs, efl-one.so will be build. > The modules of ecore / evas etc. and all the binaries will link to > efl-one.so not to the smaller libraries. However, for compatibility > reasons, and complexity reasons, the small .so's are still build and > installed. Great job! Maybe instead of building small .so's we can just symlink them all to the efl-one.so? Or would that cause symbol duplications if multiple ones are used? If it works though we can just use the efl.so name and not have to call it efl-one.so. > > If you have an app that you want to test out with efl-one: There is now > a efl-one.pc file installed, which can be used to link to the correct > libraries, no other efl dependency is then required. Why not just efl.pc? Did we ever ship efl.pc/was it ever used? I think all of the API there was beta anyway. > > From some early profiling: this saves ~1MB of memory when running a efl > app, i have so far not tested out what impact it has on runtime > performance or first frame numbers. > Super cool! -- Tom ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Time for efl-one
Hi, On 5/28/20 1:32 PM, Tom Hacohen wrote: On 27/05/2020 12:34, Marcel Hollerbach wrote: Hi, after quite a big amount of work we have successfully landed this morning a update to our build system which enables to build efl as a single big .so instead of multiple seperated .so's. The layout is that every single .so is merged into efl-one.so except: - eolian: no normal app would benefit from it, and it would make our build *a lot* more complex - ecore_avahi: there is no real user for this within efl, in general i dont think anyone is going to benefit from it - efl_canvas_wl: This is also not beneficial to a standard efl application - elua: This is only for bindings. - ecore_drm / wayland : These are deprecated libs, not to confuse with ecore_wl2 / ecore_drm2, which is included in efl-one - exactness: Not useful for a normal efl app. To build efl-one you need to pass: "-Defl-one=true" to meson. After this is done, additionally to all the smaller libs, efl-one.so will be build. The modules of ecore / evas etc. and all the binaries will link to efl-one.so not to the smaller libraries. However, for compatibility reasons, and complexity reasons, the small .so's are still build and installed. Great job! Maybe instead of building small .so's we can just symlink them all to the efl-one.so? Or would that cause symbol duplications if multiple ones are used? Yeah, something like that was planned in the future, or building small stubs without code that are just dragging in efl-one.so This way we do not have to worry about platforms with problems about symlinks etc. The problem is that the parts that are outside efl-one.so are still linking to the smaller .so's and not to efl-one.so as that is a little bit harder to realize, and I first want to ensure that we *really* have a working efl-one.so which totally works before investing more time into that. The plan for getting everything on efl-one.so looks a little different to me: - Maybe move ecore_wayland and ecore_drm to a deprecated folder, that is not handled as normal efl subproject anymore - Move elua to lua bindings and or build it from there - Find out what to do about ecore_avahi After that our normal code and build structure is in a state where everything natively links to efl-one.so simply by calling subdir(...) in another directory. We then can also automatically generate the "declare_dependency" and "library" calls and shrink down the lib meson.build files even more, which should simplify everything overall quite a bit. But thats for the future, first lets find out how this works out :) If it works though we can just use the efl.so name and not have to call it efl-one.so. If you have an app that you want to test out with efl-one: There is now a efl-one.pc file installed, which can be used to link to the correct libraries, no other efl dependency is then required. Why not just efl.pc? Did we ever ship efl.pc/was it ever used? I think all of the API there was beta anyway. efl.pc is sadly not beta anymore, shipped, and used. I basically just really want to ensure that everyone understands that this is not yet another subproject within efl, but the overall library including a lot but not everything. And in the end, its just a name ... :) From some early profiling: this saves ~1MB of memory when running a efl app, i have so far not tested out what impact it has on runtime performance or first frame numbers. Super cool! -- Tom ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Time for efl-one
On 5/27/20 6:30 PM, Marcel Hollerbach wrote: Hi, On 5/27/20 6:23 PM, Ross Vandegrift wrote: On Wed, May 27, 2020 at 11:34:57AM +0200, Marcel Hollerbach wrote: after quite a big amount of work we have successfully landed this morning a update to our build system which enables to build efl as a single big .so instead of multiple seperated .so's. The layout is that every single .so is merged into efl-one.so except: - eolian: no normal app would benefit from it, and it would make our build *a lot* more complex - ecore_avahi: there is no real user for this within efl, in general i dont think anyone is going to benefit from it - efl_canvas_wl: This is also not beneficial to a standard efl application Isn't this required by E with Wayland support? If so, it might be worth including - assuming there aren't other downsides. Yeah, good point actaully, that totally slipped my mind for now. I will see how much that adds to libefl-one.so and see what we can/need to do. Thanks! Included now, thank you for pointing it out :) - elua: This is only for bindings. - ecore_drm / wayland : These are deprecated libs, not to confuse with ecore_wl2 / ecore_drm2, which is included in efl-one - exactness: Not useful for a normal efl app. To build efl-one you need to pass: "-Defl-one=true" to meson. After this is done, additionally to all the smaller libs, efl-one.so will be build. The modules of ecore / evas etc. and all the binaries will link to efl-one.so not to the smaller libraries. However, for compatibility reasons, and complexity reasons, the small .so's are still build and installed. If this works out, will this be the default at some point? And I assume that libefl-one will be the final name to avoid confusion with the existing libefl? I think we cannot say for sure if this will get the default build or not at this point. Right now we are more in the "try it out" stage, need to see how much it helps / improves the things overall, and see what negative things might show up. I also do not know how many projects are out there that only use the stack up to ecore, or only eina / eo. For them something like this might be a nightmare. And yes: the name libefl-one is taken to not be confused with libefl. Greetings, bu5hm4n Ross ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
