summaryrefslogtreecommitdiff
path: root/src/lib/eina/eina_internal.h (follow)
AgeCommit message (Collapse)Author
45 hourseina: Rename EAPI macro to EINA_API in Eina libraryFelipe Magno de Almeida
Summary: Patch from a series of patches to rename EAPI symbols to specific library DSOs. EAPI was designed to be able to pass `__attribute__ ((visibility ("default")))` for symbols with GCC, which would mean that even if -fvisibility=hidden was used when compiling the library, the needed symbols would get exported. MSVC __almost__ works like GCC (or mingw) in which you can declare everything as export and it will just work (slower, but it will work). But there's a caveat: global variables will not work the same way for MSVC, but works for mingw and GCC. For global variables (as opposed to functions), MSVC requires correct DSO visibility for MSVC: instead of declaring a symbol as export for everything, you need to declare it as import when importing from another DSO and export when defining it locally. With current EAPI definitions, we get the following example working in mingw and MSVC (observe it doesn't define any global variables as exported symbols). Example 1: dll1: ``` EAPI void foo(void); EAPI void bar() { foo(); } ``` dll2: ``` EAPI void foo() { printf ("foo\n"); } ``` This works fine with API defined as __declspec(dllexport) in both cases and for gcc defining as `__atttribute__((visibility("default")))` However, the following: Example 2: dll1: ``` EAPI extern int foo; EAPI void foobar(void); EAPI void bar() { foo = 5; foobar(); } ``` dll2: ``` EAPI int foo = 0; EAPI void foobar() { printf ("foo %d\n", foo); } ``` This will work on mingw but will not work for MSVC. And that's why EAPI is the only solution that worked for MSVC. Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com> Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev> Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com> Reviewers: jptiz, lucas, woohyun, vtorri, raster Reviewed By: jptiz, lucas, vtorri Subscribers: ProhtMeyhet, cedric, #reviewers, #committers Tags: #efl Differential Revision: https://phab.enlightenment.org/D12188
2019-01-16eina: remove eina_promise_data_get has it lead to risky use.Cedric BAIL
It seems that use of eina_promise_data_get lead to mostly missuse. As it duplicate other infrastructure which do not have the same problem. So better remove it and if we need it back, we can just revert this patch later. Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com> Differential Revision: https://phab.enlightenment.org/D7578
2018-08-20move efreet xdg envvars to einaMarcel Hollerbach
Summary: The contents of the XDG_ env vars are also usefull for eina subsystems, thus we should init those env vars here. Depends on D6751 Reviewers: zmike, stefan_schmidt, #committers Reviewed By: zmike, #committers Subscribers: #reviewers, cedric, #committers, zmike Tags: #efl Differential Revision: https://phab.enlightenment.org/D6744
2018-07-12eina: Spelling fixesBryce Harrington
Reviewers: devilhorns, Hermet Reviewed By: Hermet Subscribers: cedric, #committers, zmike Tags: #efl Differential Revision: https://phab.enlightenment.org/D6570
2018-03-03ecore - a different take on efl.app class as a super class to efl.loopCarsten Haitzler (Rasterman)
so the MAIN loop is actually an efl.app object. which inherits from efl.loop. the idea is that other loops in threads will not be efl.app objects. thread on the creator side return an efl.thread object. inside the thread, like the mainloop, there is now an efl.appthread object that is for all non-main-loop threads. every thread (main loop or child) when it spawns a thread is the parent. there are i/o pipes from parnet to child and back. so parents are generally expected to, if they want to talk to child thread, so use the efl.io interfaces on efl.thread, and the main loop's elf.app class allows you to talk to stdio back to the parent process like the efl.appthread does the same using the efl.io interfaces to talk to its parent app or appthread. it's symmetrical no tests here - sure. i have been holding off on tests until things settle. that's why i haven't done them yet. those will come back in a subsequent commit for really quick examples on using this see: https://phab.enlightenment.org/F2983118 https://phab.enlightenment.org/F2983142 they are just my test code for this. Please see this design document: https://phab.enlightenment.org/w/efl-loops-threads/
2018-02-23eina vpath - improve docs and add app.tmp and usr.tmp vpaths tooCarsten Haitzler (Rasterman)
definitely kaes the docs better with lots of sample paths and some indication of what these may map to in real life.
2018-02-22eina: make eina_vpath_interface_app_set an internal function.Cedric Bail
I am wondering if this one shouldn't even be a private one and directly used by eina_prefix.
2018-02-22eina: make eina_vpath_interface_user_set an internal API.Cedric Bail
2018-01-18all: Simplify definition of EAPIVincent Torri
This will help in the transition from Autotools to Meson. This has been tested on Windows for which EFL_XXX_BUILD were first introduced.
2017-12-19eina: fixup EAPI definition.Cedric BAIL
2017-12-19eina: Add missing eina_internal.hJean-Philippe Andre