exactly. it was too odd. was it meson ? ninja ? some EAPI (or other similar macro) stuff ?

solved (though i still don't understand why it failed) : i unset PKG_CONFIG_PATH and it compiled flawlessly with my script. no problem with latest meson too

below are the shots of dependency walker for libevas-1.dll and libecore-1.dll

i used dependency walker which is a tool that parses the PE files (file format used for the DLL) and it reports something very strange : only 2 symbols are exported : fribidi_unicode_version and fribidi_version_info !?!?!? I don't understand, all the evas symbols should be here. There is no problem for other generated dll (ecore, eina, evil, etc...).

and include the .x file in the .h file

imho, making exactness working on Windows is a big task. What is done here is making it compile. Just looking at the diff above, I see "/tmp/etc..." which is not an existing dir on Windows

maybe i have found the problem

i think that there is one occurence here : doc/elementary_examples_cxx.dox: * @ref location_cxx_example_01

@ProhtMeyhet if there is no such warning on linux, then we can close the task

gcc for Windows, version 9.2.0. I guess that it does not detect that it is defined there :

btw, in code there are also TODO and XXX comments...

"Lastly, you've suggested to use cos rather than cosf before at D10467, jsuya agreed this patch as you can see his comment above. and I agree also."

is this accuracy really needed ?

to mimic Shakespeare:

so, what is the status of this diff ?

install_dir option

btw cosf returns a float, not a double

we can also increase _XOPEN_SOURCE to 700 (http://man7.org/linux/man-pages/man7/feature_test_macros.7.html)

otoh : https://lists.gnu.org/archive/html/autoconf/2010-08/msg00045.html it seems that we should not use __USE_UNIX98

@raster btw, eina_inline_posix_lock.x does:

@raster i've asked the user to export it to CPPFLAGS and issue vanished of course. I will provide a diff

@bu5hm4n i would say in eina as a user should not do extra work. Eina is using some features, it should enable them, imho.

it is garded. adding -D_POSIX_C_SOURCE=200809L in eina.pc (in CFlags) should be sufficient

strlcat does not exist on Windows

option b) is fine for me

Note that elementary makes ephoto unresponsive. Certainly a problem on Windows. I have plenty of this message:

we have plenty of dependencies, so if we can remove some, that would simplify everybody's life

shouldn't this be abandoned and rewritten for meson build system ?

should we add @private to the doc of the functions ?

plane reserved

no, EFL_BUILD is set in config.h, which is also used by binaries. see toplevel meson.build

maybe this should have been detected with a unit test too, no ?

i can't try the test, but i tried the code on a file, and it works with the change mentioned above

i should add a typedef in evil_private.h then. ssize_t does not exist on Windows but SSIZE_T does

why is there a diff for benchmark ?

unmark err as unused

see D9913

mprotect is in evil now. i have to define HAVE_MMAP in evil_mman.h to check if there is no problem. I'll do that today

@stefan_schmidt is this a blocker for 1.23 ?

actually, i've just checked : eina_config.h is generated independantly of eina_config.h.in

I just want to mention that long is a 32 bits type on Windows 64 bits, so you must pay attention at what is done on this platform when using long

after checking, eina_config.h has no EINA_HAS_BUILTIN macro (at least on Windows) with latest git of today(august 31st 2019) with gcc as compiler. Is it normal ?

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 :