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
