|Age||Commit message (Collapse)||Author|
This reverts commit d6294fa22b88187e44391c1c8ca64b1ebdf14533.
setenv and unsetenv are not portable. i explained to you at fosdem
there are issues and it's why i used putenv in the original
implementation and even though it's a pain (the string tou pass to
putenv is a pointer used literallt from there on in and you get it
from getenv, thus making ownership a pain -this is a libc issue we
can't readily solve). use putenv like the original code. then put it
back in. vtorri now has windows porting issues with the setenv use. i
knew there was a reason that still existed...
in addition your in_sync stuff is broken. psuedocode:
// assuming BLAGH env is not set to anything here
c = efl_core_env_get(global_env, "BLAH");
c = efl_core_env_Get(global_env, "BLAH");
i will get NULL in both cases for c ... but i should get "10" for the
2nd in reality. reality is lots of code across application code and
libraries will at times mess with the environment. it has to work with
this. the prior implementation did work with this.
Revert "ecore: here comes a env object"
This reverts commit 2373d5db5b4cd5dfe139aa2a10017ef61b28b5ce.
Revert "efl_task: remove env from this object"
This reverts commit c3d69f66a69c0def357a5c373a13343e1c01ff5d.
the env object can be used to alter and edit the content of environment
variables. Additionally, the class efl.core.env can be used to to setup
a not applied set of environment variables, which then can be applied
later (in the future) to set it directly to a spawned process for
example, or as a general key/data storage. A efl.core.env object can
also be forked off, which makes it easy to customize predefined objects.
Differential Revision: https://phab.enlightenment.org/D7510
Differential Revision: https://phab.enlightenment.org/D7416
don't set -msse3 unconditionally - set the correct flags based on
architecture. now it builds on arm, aarch64 again as well as x86. sorry -
can't test ppc as i have no such hardware.
also use host_machine not target_machine. target is wrong that's only
for cross compilers (if we were compiling a cross compiler and the kind of
binary they may produce, not what they run on - that's host).
you were not able to disable the header checks, so if the header was not
there it indicated that you could turn it of. However, the option check
was in the has_header if not outside of it. Further more, header checks
are done in the subdirectory that is done for header checks,
unneccessary cpu_**** flags are removed, global optimization options are
added to the global_arguments instead of just the package_c_args, which
leads to the fact that also all binaries etc. are build by default with
those optimization flags.
This also reduces the amount of options to a minimum of 1 option, to
just control if there should be the optimization or not.
This also changes from host_maschine to target_mschine, since we
probebly want to enable the optimization for the target maschine, not
Differential Revision: https://phab.enlightenment.org/D7296
this fixes the building for systems where int and long does not have the
Differential Revision: https://phab.enlightenment.org/D7143
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 <firstname.lastname@example.org>
Differential Revision: https://phab.enlightenment.org/D7012
Depends on D7011