Summary:
Patch from a series of patches to rename EAPI symbols to specific
library DSOs.
= The Rationale =
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>
Reviewers: vtorri, jptiz, woohyun, lucas, SPAM-smith78899
Reviewed By: vtorri, SPAM-smith78899
Subscribers: SPAM-smith78899, raster, SPAM-cabanacatalogs, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D12228
this way we can use that list easily in the modules, and keep the list
for later module building.
Differential Revision: https://phab.enlightenment.org/D11897
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
Adding it to all missing places so we can control it from the central
meson.build file.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Reviewed-by: João Paulo Taylor Ienczak Zanette <joao.tiz@expertisesolutions.com.br>
Differential Revision: https://phab.enlightenment.org/D11855
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
Summary:
before recent times we had to support static and shared building based
on the options of the user, which forced us to complicate our build with
the evas_goal hack. the evas_goal hack more or less was the idea of
"faking" the evas build in the evas directory, finish all the .eo
generation there, then build the modules and make all the static files
ready. Then build everything in evas_goal.
Now, that we just build everything the same always, we can simply build
it in the evas way (removing the evas_goal hack FINALLY), as the same modules
are build statically and shared.
This also gives us the possibility to build the shared image loaders
*again* the the modules directory, which unbreaks peoples build scripts
who packaged loader files seperatly.
Reviewers: zmike, raster, cedric, stefan_schmidt
Reviewed By: zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10548
if your platform is picky enough it won't want to leave unresolved
symbols (which wshould be resovled at runtime from the host lib) so we
need to link these modules to evas. the problem is due to the
complicated build of some modules being static and some shared, evas
is declared with evas_goal and this has to be declared after static
modules are declared but since i was declaring static and shared at
the same time from a table this breaks. so i have to move all the
static and shared module stuff into evas_goal into 2 phases. one phase
for the static and one for the shared after evas is delcared so evas
as a target exists to link to.
so the evas modules able to be static or not was a bit pointless as it
could inline all evas modules (or none) not just the most common or
not, but ecore evas modules were still modules, so it really wasn't
being useful.
image loaders ans savers omn the other hand were *ALL* being
statically built in without exception. this was kind of a regression
in the build system in the move to meson. some were static due to
micro optimizations and performance inlining the most common to save a
little extra loading + linking + page fragmentation for loaders you
are likely to need in most cases as well as save the drity pages from
linking in their dependencies (libgif, libtiff, libwebp and all their
dependencies too etc. etc.). this now brings back the ability to
decide which are static and which are shared modules (not exposed to
the user as options for meson - fixed in meson.build files which i
think is good enough given the purpose of this).
Summary: This fixes especially the execution of edje_cc on Windows
Test Plan: execution of edje_cc
Reviewers: cedric, raster
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D7834
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
This enables the PNG saver to save images with gray and
alpha + gray colorspaces. GRY8 is usually used for alpha only.
Note: This commit also introduces whitespace changes. Sorry
about the mess, but at least now we have spaces only. Read the
commit with show -w :)
@feature
Summary:
Returning from default would result in memory leak of f. Now the memory
is not leaked.
Signed-off-by: Srivardhan Hebbar <sri.hebbar@samsung.com>
Reviewers: cedric
Differential Revision: https://phab.enlightenment.org/D3272
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
This reverts commit 5beb47aa4d.
Revert "image_savers/jpeg: fix undefined behavior of using sigsetjmp on jmp_buf"
This reverts commit 84c7751e19.
these end up with efl simply not compiling. efl tree does not build at
all now and this warrants a revert.
lib/evas/.libs/libevas.so: undefined reference to sigjmp'
collect2: error: ld returned 1 exit status
Makefile:19321: recipe for target 'bin/evas/evas_cserve2' failed
.. etc.
Carsten Haitzler
Vincent Torri
Felipe Magno de Almeida
Elyes HAOUAS
Marcel Hollerbach
Stefan Schmidt
Mike Blumenkrantz
Pawel Aksiutowicz
Jean-Philippe Andre
Cedric BAIL
Vincent Torri
Srivardhan Hebbar
Daniel Kolesa
Bogdan Devichev
