Page MenuHomePhabricator

eolian: Add -e parameter to pass export symbol to eolian generator
ClosedPublic

Authored by felipealmeida on Nov 25 2020, 6:47 AM.

Details

Summary

Eolian generator must have a parameter so it can generate the correct
symbol export/import macro for the API generated.

This makes it possible to define the symbols as being local to a
single DSO without the need to guard the generated headers or
generated source files with #define and #undef preprocessor
statements.

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>

Diff Detail

Repository
rEFL core/efl
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
felipealmeida created this revision.Nov 25 2020, 6:47 AM

It seems that this patch has no reviewers specified. If you are unsure who can review your patch, please check this wiki page and see if anyone can be added: https://phab.enlightenment.org/w/maintainers_reviewers/

felipealmeida requested review of this revision.Nov 25 2020, 6:47 AM

are you sure that the summary is correct ?

src/bin/eolian/main.c
5

why is evil needed ?

7

is getopt.h available with Visual Studio ?

felipealmeida edited the summary of this revision. (Show Details)Nov 26 2020, 2:16 PM
felipealmeida edited the summary of this revision. (Show Details)

Removed unnecessary changes to include headers

_eolian_api_symbol is not freed, is it normal ? i know that anyway the mem is freed when the prog is shutdown, bu i prefer to mention it

_eolian_api_symbol is not freed, is it normal ? i know that anyway the mem is freed when the prog is shutdown, bu i prefer to mention it

Thanks for mentioning. It was lazyness on my part. I'll fix it.

Fix leaking _eolian_api_symbol

for me, it compiles, there is only the note i added
if @q66 could look at this, that would be nice

src/bin/eolian/sources.c
501

"const Efl_Class *klass = " is removed, is it normal ?

felipealmeida added inline comments.Nov 30 2020, 6:59 AM
src/bin/eolian/sources.c
501

There is something strange here indeed. I think some problem with conflicts

felipealmeida added inline comments.Nov 30 2020, 7:10 AM
src/bin/eolian/sources.c
501

I'll be looking into it today.

lucas added a comment.Nov 30 2020, 8:46 AM

Besides @vtorri's points, everything seems fine for me. I will just wait for the resolution of those to give my approval.

Remove changes that came from merge conflict

felipealmeida marked 3 inline comments as done.Nov 30 2020, 1:07 PM

The whole change was removed, it didn't make any sense. It was basically a wrong revert applied by conflicts

lucas accepted this revision.Dec 3 2020, 12:08 PM
This revision is now accepted and ready to land.Dec 3 2020, 12:08 PM
vtorri accepted this revision.Dec 4 2020, 12:38 AM

ok for me too

This revision was automatically updated to reflect the committed changes.