diff to review : #9542

include mman.h in raw generic module

I don't understand. It's like the other EFL header inclusions which are not part of the lib. Look at all the Eina.h inclusions for examples

i plan to remove sys/mman.h from evil and just a private evil_mman.h (included by evil_private.h)

there is no mman.h on Windows, only in Evil. It's currently exported. I want to make it private in Evil (creates an evil_mman.h, included in evil_private.h), then :

also, there are a lot of files that include sys/mman.h without guarding it with HAVE_SYS_MMAN_H. They must be guarded, right ?

@raster D9493
@bu5hm4n D9494

@raster yes, they are functionnaly equivalent. i've already implemented it on my computer. I'll provide a diff soon for it

@bu5hm4n you added the definition of HAVE_MMAN_H : https://git.enlightenment.org/core/efl.git/commit/header_checks/meson.build?id=46d464e5bfc10398461a33a2256c1c58d509dd1a

@raster VirtualProtect can be used. Also, mprotect exists in FreeBSD since BSD 4.4 [1](quite old), and is in POSIX 2001 [2] and solaris

i do get warnings on 64 bits, that's why i've spotted them

fixed by D9392

i'll be away from the computer with the changes until end of august. If changes are requested, apply the patch and do the modifications after, thanks

i'll be away from the computer with the changes until end of august. If changes are requested, apply the patch and do the modifications after, thanks

i'll be away from the computer with the changes until en of august. If changes are requested, apply the patch and do the modifications after, thanks

use error_cb to report error

which error should I use ? 0 ?

you mean calling :

verify that config.h has HAVE_CHOWN and HAVE_GETPWENT in config.h on linux

fix T8062

are they really in md format ?

this patch disable debugging threads on windows and the compilation passes eina (until the next error in eldbus...)

or maybe define EINA_HAVE_DEBUG_THREADS if backtrace in execinfo.h exists :

maybe we can at least guard this with HAVE_EXECINFO_H ?

yes, but there are other problems that appear later. All the eina_debut stuff actually. @raster told me that anyway it's not working anymore. I'll let him explain better than me

something like that :

note that backtrace() can be replaced on Windows with CaptureStackBackTrace, see :

what about line 151 which already adds harfbuzz as dep ?

a test in header_check/meson.build should be added then of course

HAVE_GETPWENT is wrong, btw, no ? it should be HAVE_GETPWNAM

use HAVE_GETPWENT to know if user fetching is available directly in vpath_resolve

why doing all the tests and calling a function for nothing ? If you want me to add a more explicit error message, like ERR("Windows platform does not support ~username vpath"); no problem,

@bu5hm4n where ? there is just a call to ERR() and it returns 0. You want me to add a call to ERR() ?

make doc too ?

@bu5hm4n no, it's you who added this test : https://git.enlightenment.org/core/efl.git/commit/src/static_libs/draw/meson.build?id=500a36ba3d3d00ed292ed3e85bb9ac40a55bd2a9

i'll will try to test on Windows next week

lgtm

Im' against that. CFLAGS exists for such purpose

bsearch exists on windows : https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/bsearch?view=vs-2019

when you have time, can you check, please ?

can you please modify it so that evas_common_copy_pixels_c() is inlined and see if there are perf improvements ?

is it working on Windows ?

that's what is done in configure.ac. I first trust what is in it.

do a git grep EINA_DEBUG_MALLOC

in src/lib/eina/meson.build, instead of

should EAPI_INTERNAL EAPI really be part of the API ?

what about making this function inline ?

cf D9107

i wasn't aware of this diff :-)

the problem is not EAPI, the problem is evil_locale.c which includes evil_private.h wich includes evil_macro_wrapper.h which defines setlocale() from evil_setlocale, setlocale being used in evil_locale.c

i don't want to add another header file just for evil_locale.c

for each binary, EFL_BUILD must not be set. For each library, EFL_BUILD must be set. We must be sure that this is correctly done with meson. As I have said, it's a reminder for meson (see last line of my original message)

with autotools (me), edje_cc at least displays help
with meson , zmike told me that edje_cc displays nothing