meson has a builtin option to pass some warning flags to compiler. 'warning_level=1' passes -Wall
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D12315
Summary:
This is a 8 commit patch, but only for a while - after agreeing with
each of the changes, it shall be squashed into a single commit.
I want to make further changes on meson.build (maybe I can end up simplifying
the build system, or just let things more organized in the end) and thought
that starting with a cleanup would be a good first step.
The changes are:
1. build: set arguments scope to project instead of globally
If we set arguments globally, it may conflict with other builds - specially
considering [meson's subprojects
feature](https://mesonbuild.com/Subprojects.html). Setting to project
arguments ensures we are only considering EFL and not leaking unwanted flags.
2. build: Fix spacing and indent
Mostly because it is not well standardized during the file - sometimes
there's spaces between tokens, sometimes there is not, etc. The same applies
to indent.
3. build: move test environment closer to test commands
Just as a matter of organization. If we're doing things for tests that don't
impact other stuff, then leave it when tests are handled.
4. build: Remove unnecessary parenthesis and == true comparisons
Less noisy redundancy: `true` is already true, and `false` is already false,
no need to re-check. Besides, reading `if sys_windows` and `if sys_windows
== true` shouldn't have different effects, as the first you can read as "if
the system is windows". It gets better when you have `not` instead of `==
false`, so for an example you could read `if not sys_windows` as "if it is
not a windows system" more naturally.
5. build: Switch pc_files to dict
Just thought it could stay a little better (since it works as a dict),
specially in the `foreach` right after.
6. **[removed to a future patch]** build: Use meson's warning_level instead of hardcoded -Wall
This way we ensure this is compiler-independant (and use the correct feature
for that, since meson even warns when configuring the build dir).
7. build: Use language args from add_project_arguments properly instead of a loop
The `language:` kwarg from `add_{project,global}_arguments` receives a list
of languages, so no need for that loop.
8. **[removed to a future patch]** build: Use '/' instead of join_paths
As it [is recommended by meson since
v0.49](https://mesonbuild.com/Release-notes-for-0-49-0.html#joining-paths-with-)
(and stays clearer IMO, specially since that's how some languages are
adopting path separation, e.g. C++'s filesystem stdlib).
Reviewers: bu5hm4n
Subscribers: vtorri, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11994
When we jumped from 0.47 to 0.52 to fix problems some users have been
seeing when building we might jumped a bit to far. We want a good
balance between stable and fast building but also mature enough to be in
distro releases and widely available.
We will try to settle for a middle-ground with 0.50 here. If that causes
problems for you building please let us know instantly.
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
Normally we would set the needed detect_odr_violation=0 form our CI
scripts. Move it here to ensure we have it set and it does not get
forgotten when meson overrides the env far.
Fixes the ASAN job on CI.
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D11902
this was missed before, so the subdirectories have not been correctly
added. With this you can now simply build with efl-one with including
<Elementary.h>
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11893
this is building parts of efl into a single .so and links all modules
and binaries to it.
The libraries themselfs are build as .a's which are linked together as
.so's. Which is required as every subproject has its little custom
c_flags, which are somtimes conflicting.
After the final .so is then built, all the split up libraries are
replaced with the efl-one. After that the modules and binaries are built
correctly with the correct link on the efl-one parts.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11808
this is needed as a preparation for more build refactoring. Overall goal
to build efl in a single .so.
What this commit results in is that *every* lib gets build first, then
the modules and binaries of all subprojects. This way of building is
needed in order to replace the split up libraries with the efl-one one
later.
Additionally, the infrastructure is added to set flags on the libraries
that should be build together.
Reviewed-by: Stefan Schmidt <stefan@datenfreihafen.org>
Differential Revision: https://phab.enlightenment.org/D11805
Summary:
The same principle we use for the build stage we use here for running
our tests. Leak detection has just to many problems for us on the
shutdown path that it makes no sense to use here.
I am also bumping the evas timeout form the default 30s to 60 as I have
been running into timeouts with asan enabled on my machine. This would
not change anything on a default build.
Depends on D11137
Reviewers: smohanty, bu5hm4n, raster, zmike
Reviewed By: zmike
Subscribers: zmike, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11862
Original patch by Vincent Torri. Co-authored with Marcel Hollerbach.
fixup
Reviewed-by: Vincent Torri <vincent.torri@gmail.com>
Reviewed-by: João Paulo Taylor Ienczak Zanette <joao.tiz@expertisesolutions.com.br>
Differential Revision: https://phab.enlightenment.org/D11851
No need to have this elementary specific, we can do this globally.
Original patch by Vincent Torri.
Differential Revision: https://phab.enlightenment.org/D11850
Signed-off-by: Stefan Schmidt <s.schmidt@samsung.com>
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:
this is a useful warning to avoid errors when calculating pointer offsets
Depends on D11816
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11817
We missed to actually set the ENABLE_LUA_OLD. Ross run into some
problems with Lua 5.2 builds and we hope this fixes the issue for him.
Found and fixed by Marcel Hollerbach (only put in the system by me).
Fixes T8705
Summary:
this is needed in order to return the data the same way the legacy impl
did. This however has the annoying sideeffect that ecore_evas_x now
depends on efreet, and we had to change the build order.
Depends on D11696
Reviewers: zmike, stefan_schmidt, raster
Reviewed By: zmike
Subscribers: devilhorns, cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11697
this is needed in order to support ecore-evas loading of .so modules
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11651
We do not want to have EAPI from exactness exposed at this point without
any real user. I know of no application using the exactness library.
If we come to that point we can move things back into a lib, but for now
having the code shared between the various executables is all we need.
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11545
Summary:
this is a canvas object so it needs to be in the canvas namespace
Depends on D11475
Reviewers: segfaultxavi, bu5hm4n
Reviewed By: bu5hm4n
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11476
Summary:
this converts the main efl-wl object to an eo-based canvas group object
Depends on D11465
Reviewers: segfaultxavi, bu5hm4n
Reviewed By: bu5hm4n
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D11454
Exactness has been developed in a separate git repo for many years. This
finally moves it over into efl. Having it in tree allows us for easier
testing with our current main target elementary_test and integration
into our CI system (patches for this are work in progress already).
We are only importing the lib and binary for test execution, not the
full set of test data. This is would be over 500MB and thus it will stay
in a different repo and only made available during the actual testing.
[The original patch was made by Daniel Zaoui. Over the course of review
and testing it got extended with build fixes for API changes and mingw
compilation support from Stefan Schmidt and Michael Blumenkrantz]
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Differential Revision: https://phab.enlightenment.org/D11285
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
This has never been fully finished or really used. The GeoClue project
dbus API moved on to a newer version as well. We still have it marked as
beta so we should take the chance and get rid of it to cleanup our tree
a little bit.
Reviewed-by: Chris Michael <cp.michael@samsung.com>
Reviewed-by: Vincent Torri <vincent.torri@gmail.com>
Differential Revision: https://phab.enlightenment.org/D10788
Summary:
When pulling in OpenSSL and building against the
port there are some linker complications.
For example, doing a TLS HTTP transaction will
crash in libcurl which was built against
OpenSSL in base. If we link against FreeBSD's
OpenSSL these issues are resolved.
Test Plan:
On FreeBSD use the openssl port and build EFL
against it.
1) Upload a screenshot in E (segv).
2) Click on a link to image in terminology over
HTTPS (segv).
Reviewers: bu5hm4n, raster
Reviewed By: raster
Subscribers: cedric, Peter2121, #reviewers, q66, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D10789
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.
evas-modules affects evas engine modules if they are static or shared,
but ecore evas modules are still modules... so all in all this doesnt
help much as it still requires modules to be separate from the shared
libs, thus disallowing for statically linking efl into an app anyway
etc. etc. etc. ... so less options to deal with, less complexity.
better.
Vincent Torri
Carsten Haitzler
Marcel Hollerbach
Stefan Schmidt
Daniel Kolesa
João Paulo Taylor Ienczak Zanette
Stefan Schmidt
Mike Blumenkrantz
Daniel Zaoui
Ross Vandegrift
Alastair Poole