Summary:
Patch from a series of patches to rename EAPI symbols to specific
library DSOs.
= The Rationale =
This patch is 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
LIBAPI is the only solution that works for MSVC.
Co-authored-by: João Paulo Taylor Ienczak Zanette <jpaulotiz@gmail.com>
Co-authored-by: Lucas Cavalcante de Sousa <lucks.sousa@gmail.com>
Co-authored-by: Ricardo Campos <ricardo.campos@expertise.dev>
Reviewers: vtorri, woohyun, lucas, jptiz
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12210
Summary: I found wrong API reference group name in mapbuf, Evas, Eet, Eina, Eio and fixed them.
Test Plan: API reference documentation modification only
Reviewers: segfaultxavi, stefan_schmidt
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12052
what is happening is that a file gets announced through eio_model
listing code, at this point of time, the monitor does not yet know about
the file. If the file now gets deleted between the annoncing and the
learning of the file from the monitor, then the file got an ADD event,
but no DEL event. Which is a bug.
With this commit there is a new API which asks the monitor if the file
already has the knowledge about the files existance, or not. A few
monitors like win32 inotify or cocoa do not have context about the file
directly, if the OS is now having the same bug, then we are again in
trouble, however, we canot do anything about that. In the case of kevent
or poll, this asks the context of the monitor if the file is already
there.
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10006
the fallback method of calling stat() on the monitored paths does not allow
for various eio events to be emitted, meaning that any application which relies
on those events can never receive them
this provides a method for checking a monitor to determine which functionality
is available, and also provides more explicit documentation regarding events
that are not provided by fallback monitoring
this method is marked as beta
@feature
Differential Revision: https://phab.enlightenment.org/D6447
The legacy Eio_File factory functions are replaced by an Eo object
called Eo_Job that return promises wrapping the async file operations.
With this commit, the legacy Eio callbacks are replaced by the following
Eo/Promises counterparts :
* Done_Cb -> Promise then success callback
* Error_Cb -> Promise then error callback
* Main_Cb -> Promise progress callback
* Filter_Cb -> Job object event (more below)
Events are used to deliver and get the filter data. To differentiate
between the named and direct versions, they come in "filter,direct" and
"filter,name" versions.
Monitors were wrapped inside a new class Eo_Sentry.
The user creates a sentry object and adds monitoring targets to it,
listening to events on it.
The sentry event info is composed of two strings. The source string
is the path being monitored, i.e. the one passed to eio_sentry_add, and
the trigger string is the path that actually triggered the event, e.g.
a new file created in a monitored directory.
Felipe Magno de Almeida
Myoungwoon Roy, Kim
Xavi Artigas
Marcel Hollerbach
Vincent Torri
Mike Blumenkrantz
Mike Blumenkrantz
Jee-Yong Um
Lauro Moura