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>
Reviewers: q66, vtorri, woohyun, jptiz, lucas
Reviewed By: vtorri, lucas
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12197
This was meant to happen but did not previously happen. It is not
ideal to do it now but better do it while we still can.
In short, this removes one half of the variables API (keeps
constants as they are) and repurposes the API to be only for
constants. This is also better for consistency to match errors.
This is unnecessary because for all contexts where type is
relevant the validator already makes sure the type and expression
match correctly, so you don't ever need to re-validate it. If you
are doing a generic case and are not sure, just use MASK_ALL.
Summary:
This commit changes the beta ness of a few types, those types are
looking quite stable. Edje types will likely not change. The
Efl.Gfx.Join types are actaully already stable since the last release,
since evas_vg was stable back then and those enums have been in there.
The elementary stuff looks a bit unthought, and we have the chance to
change the API in the backend, so maybe we want to not declare it
stable, but rather reintroduce the legacy types.
With this we can enable eolian generation of beta tags for types.
ref T7726
Depends on D8276
Reviewers: cedric, segfaultxavi, zmike, stefan_schmidt, q66
Reviewed By: segfaultxavi, q66
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7726
Differential Revision: https://phab.enlightenment.org/D8277
Summary:
This also simplifies the beta checking API by unifying it under
objects (makes much more sense that way) and reworks the validator
to have betaness support within its context state, allowing checks
to be done easily in any place.
The betaness checks are disabled for types for the time being,
because otherwise there are too many errors (types are assumed
to be stable as they are not tagged beta, but they reference beta
classes all over the place). Set EOLIAN_TYPEDECL_BETA_WARN to 1
in your environment to force enable the checks.
Reviewers: zmike, bu5hm4n, stefan_schmidt, lauromoura, cedric
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl, #eolian
Differential Revision: https://phab.enlightenment.org/D8102
Doc refs no longer introduce new dependencies into files. Instead,
they're parsed globally, and any doc ref lookup is also made
globally. This allows unit based dependencies to correspond more
to what files actually really need at compile time/runtime, with
docs being irrelevant to that; it also simplifies the API.
The doc resolution API now takes Eolian_State instead of
Eolian_Unit, too.
As it is no longer necessary to pass unit when evaluating exprs,
it is not necessary to pass it here either. Convert all the APIs
to the new style and update all instances in our tree.
These types are of questionable value and the API was not entirely
thought out - remove for now, and if a legitimate use is found
later, they may be readded (with a better API), but typically it
seems best to redesign the bad APIs around safe containers...
First steps toward explicit function pointer support in eolian.
To declare a function pointer type, use the following syntax, similar to
a regular eolian method declaration.
function FunctionName {
params {
...
}
return: Return type
}
Felipe Magno de Almeida
Daniel Kolesa
Marcel Hollerbach
Daniel Kolesa
Daniel Kolesa
Lauro Moura