Commit Graph

2 Commits

Author SHA1 Message Date
Felipe Magno de Almeida a594413ccb elementary: Rename EAPI macro to ELM_API in Elementary library
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>
2020-10-11 13:00:04 -03:00
Mike Blumenkrantz ca9daf94c6 elm_code_widget: make this efl_ui namespaced
this currently has no counterpart in interface widgets but would be
useful there. removing the use of an elm_scroller type makes it independent
of legacy widgets, and it's still a beta api so at least future development
can be resumed at some point without much issue

Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8158
2019-03-07 14:14:55 -08:00