Summary:
Not everyone has a system or libraries that need to conform with
Freedesktop standards, making efreet not necessary on them.
This patch solves this by making efreet an optional library.
Test Plan:
`meson test -C build` + run edje, evas and elementary examples to
see if nothing got weird.
Ref T8814
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Maniphest Tasks: T8814
Differential Revision: https://phab.enlightenment.org/D12151
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>
libraries are split into deps, external deps, and pub deps.
Evas engines are refactored to use the predefined engine deps.
this is preparation work for efl-one.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11806
Summary: EAPI must be defined to dllexport when building DLL, and to dllimport when using these DLL. To achieve this, define EFL_BUILD for each library and module, and set DLL_EXPORT unconditionally. Static library are and will be not supported
Test Plan: compilation
Reviewers: zmike, raster, jptiz
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11834
In EFL we have multiple hirachies of parts. One in Efl.Layout namespace
(alias edje) and one in Efl.Ui namespace. The seperation of these two
makes sense from the perspective of hiding functionality. However, a
functionality that we want to have on both is: we want to be able to
check which type of part this is. In order to do so, this commit
introduces a common interface, which allows that.
This is required because eo is currently undergoing some works, where
only APIs on a object are allowed, that are also inheriting its type,
which is normal in OOP, but sometimes, due to the lack of limitation, we
did that. This commit resolves one more case of that.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11516
this includes all related headers
ref T8274
Additional Authors: Lauro Moura <lauromoura@expertisesolutions.com.br>
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D10228
this has no relation to legacy and should not be included in legacy headers
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D10227
Summary:
this is done because .eo files are not stable, and in order to stop
people depending on it, its better for now to disable the installation
of them for now.
ref T7676
Reviewers: stefan_schmidt, cedric, zmike, devilhorns
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Maniphest Tasks: T7676
Differential Revision: https://phab.enlightenment.org/D7897
this takes the current generated output from eolian for legacy code in
evas and adds it to the tree, then removes legacy references from the
corresponding eo files. in the case where the entire eo file was for
a legacy object, that eo file has been removed from the tree
ref T7724
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8130
this takes the current generated output from eolian for legacy code in
evas and adds it to the tree, then removes legacy references from the
corresponding eo files. in the case where the entire eo file was for
a legacy object, that eo file has been removed from the tree
ref T7724
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8129
this takes the current generated output from eolian for legacy code in
evas and adds it to the tree, then removes legacy references from the
corresponding eo files. in the case where the entire eo file was for
a legacy object, that eo file has been removed from the tree
ref T7724
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D8128
this patch is for selecting lua interpreter such as luajit, lua51
and in addition, little more changes to unify lua dependency over efl
Reviewed-by: Marcel Hollerbach <marcel-hollerbach@t-online.de>
Differential Revision: https://phab.enlightenment.org/D7564
This uses the meson/ninja depfile functionality + eolian to make
sure proper dependencies between generated files and .eo files
are managed, to ensure consistent re-generation of all generated
files that are affected upon .eo file modification.
For custom rules with multiple outputs, Ninja currently does not
support depfiles. Therefore, split those into two custom rules
so that the depfiles functionality can be enabled. While this
is ugly and slows down the process a little by having to invoke
Eolian twice instead of once, it has to be done and it's still
better than what we had in Autotools anyway.
Differential revision: D7187
Fixes T6700.
a new shiny buildtool that currently completes in the total of ~ 4 min..
1 min. conf time
2:30 min. build time
Where autotools takes:
1:50 min. conf time
3:40 min. build time.
meson was taken because it went quite good for enlightenment, and is a traction gaining system that is also used by other mayor projects. Additionally, the DSL that is defined my meson makes the configuration of the builds a lot easier to read.
Further informations can be gathered from the README.meson
Right now, bindings & windows support are missing.
It is highly recommented to use meson 0.48 due to optimizations in meson
that reduced the time the meson call would need.
Co-authored-by: Mike Blumenkrantz <zmike@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7012
Depends on D7011