Commit Graph

10 Commits

Author SHA1 Message Date
Felipe Magno de Almeida d222e43b07 elua: Rename EAPI macro to ELUA_API in Elua 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-20 09:11:25 -03:00
Daniel Kolesa 86ee71ce4d elua: do not link to cffi, load the module instead 2020-07-31 19:01:53 +02:00
Daniel Kolesa c3a1060b94 build: disable elua by default, plus nicer detection
Elua is now disabled by default. There are some other changes:

1) Elua scripts are only installed if Elua is enabled
2) Lua bindings are only installed if Elua is enabled
3) Elua with interpreter is clearly experimental and will message
2020-06-06 19:28:26 +02:00
Daniel Kolesa 5197200ac1 elua: allow building with interpreted (non-luajit) lua
This doesn't fully work yet as e.g. Eolian bindings require
the bitop module only present in luajit for now.

In order to build, you will need to install

https://github.com/q66/cffi-lua

in order to provide the FFI. It needs to be built for the Lua
version you are building EFL with.
2020-05-29 16:40:05 +02:00
Carsten Haitzler 63b5d81983 Revert "Fix EAPI definition by defining EFL_BUILD for each built DLL"
This reverts commit 3ade45cbc8.
2020-05-18 11:13:59 +01:00
Vincent Torri 3ade45cbc8 Fix EAPI definition by defining EFL_BUILD for each built DLL
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
2020-05-18 09:51:48 +01:00
Ross Vandegrift 2e854ce7ed correct edje pkg-config generation for luaold
Currently, edje.pc gets its lua Requires from the -Dlua-interpreter argument.
If -Dlua-interpreter=lua, an unversioned lua entry ends up in Requires, which
cannot always be satisifed.  The evas filters meson.build handles this case by
generating a version-specific entry.  This patch copies that logic into the top
level meson.build, and passes the result to the edje subproject.

Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D10965
2019-12-28 10:47:46 +01:00
Marcel Hollerbach a6d256cb6a build: fix macos build
Summary:
it the .pc file of luajit carries linker flags that causes compilation
fails on macos, thus we need to split up the .pc file into our own
dependency, and use it with causion

Reviewers: zmike, cedric, segfaultxavi

Reviewed By: zmike

Subscribers: #reviewers, #committers

Tags: #efl

Differential Revision: https://phab.enlightenment.org/D7995
2019-02-22 08:53:20 -05:00
Wonki Kim 56a91961ce meson: add a option for selecting lua interpreter
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
2019-02-21 20:49:00 +01:00
Marcel Hollerbach 46d464e5bf here comes meson
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
2018-10-02 17:22:50 +02:00