remove objc support

remove unused c++ files, clean up configure.ac

i've applied it and unit tests are successful, so ok for it

In D12034#229727, @felipealmeida wrote:

I don't want to install an application to be able to compile or download dependencies. This makes no sense at all IMO. If we're not going to have wrap dependencies, we still need to be able to tell where dependencies are without pkg-config.

note that, for ecore, the handle returned by _beginthreadex() must wait with the WaitFor* functions, that is, it must be used with ecore_main_win32_handler_add()

for expedite, with and without -y parameter (async on/off)

try also expedite (https://git.enlightenment.org/tools/expedite.git/) with the software (gdi or ddraw) backend to benchmark it, compared to the current efl git

test this program on linux, then test it on windows and see if it is working nicely

people who are compiling the EFL are very few : packagers (unix world), and devs. Packagers don't need wrap stuff at all. They represent 99% of the people who compile
the others are devs. And the devs are those who compile on unix and those who compile on Windows
and on Windows, there are those who compile with gcc, and the others for Visual Studio

and I honestly think that it is not the purpose of the EFL build system to build the dependencies. It will add too much stuff to meson

i'm not very fond of wrapping in meson, because you don't have any control on how the lib is built. For example, is zlib built using the asm files ?

@stefan_schmidt is there something else to do ?

fix case when map is found in the hash table

In D12022#229397, @jptiz wrote:

In D12022#229396, @vtorri wrote:

In D12022#229395, @jptiz wrote:

In D12022#229393, @vtorri wrote:

i've looked at https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#fully-qualified-vs-relative-paths and i indeed see it can begin with \ (but not /) :

"A file name is relative to the current directory if it does not begin with one of the following etc... "
"A single backslash, for example, "\directory" or "\file.txt". This is also referred to as an absolute path."

i don't know if you should also consider /

It's common for applications ported to windows to consider both \ and / (e.g. neovim). Maybe it would be a nice idea if EFL accepted both as well? At least in Windows.

we do almost nothing about that. Usually, when one passes a path to a Windows file API, the API changes all the slashes to backslashes

Hm, so you mean that in EFL's point of view, it doesn't matter if the path is with \\ or /, the only one who would and should care is the underlying OS API (which will then report if the path is or not valid)?

and if an application is not working correctly wrt (back)slashes, then i consider this as a bug

In D12022#229395, @jptiz wrote:

In D12022#229393, @vtorri wrote:

i've looked at https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#fully-qualified-vs-relative-paths and i indeed see it can begin with \ (but not /) :

"A file name is relative to the current directory if it does not begin with one of the following etc... "
"A single backslash, for example, "\directory" or "\file.txt". This is also referred to as an absolute path."

i don't know if you should also consider /

It's common for applications ported to windows to consider both \ and / (e.g. neovim). Maybe it would be a nice idea if EFL accepted both as well? At least in Windows.

i've looked at https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#fully-qualified-vs-relative-paths and i indeed see it can begin with \ (but not /) :

more a coding convention

last thing for me : we declare variables always at the beginning of the block (exception in eo/eolian)
otherwise, good for me (tested)

seems good to me

In D11993#228984, @felipealmeida wrote:

In D11993#228942, @vtorri wrote:

now look at what i have written :

[snip code]

5 modified files, 4 libraries (evil, eina, eolian, eo), patch of 95 lines. I've verified that for each of these 4 libs, EAPI is dllexport, and for eolian_gen, it's dllimport

Why should eolian_gen be dllimport?

with my patch,there can't be any, by the very definition of EFL_XXX_BUILD that i am doing

do you realize that, with this kind of changes, you are going to change almost all the files of the EFL ?

@walac your prefer this patch which modifies 143 files, ONLY for eina, to my patch, which modifies 5 files for 4 libraries, with the same result ?? that's crazy

for 8, i am not against /. Windows file system understands / as path separator, so same path separator for all the OS

now look at what i have written :

In D11993#228899, @felipealmeida wrote:

and in case you don't know, i've supported Visual Studio build system for the EFL during years , with only EAPI and not a macro for each library.

I imagine your pain! Just because something is possible, doesn't mean it is a good thing.

In D11993#228897, @felipealmeida wrote:

In D11993#228894, @vtorri wrote:

i'm against this patch.

• Even if EAPI is only needed in the header file, we keep EAPI in source file so that it is easier to see the definition of public symbols

There are sometime warnings when used in definitions. But I'm not against in keeping it. I can re-add them in .c files in a new patch if you want.

• it's perfectly possible to define correctly EAPI without modifying all the files

This patch fixed two errors that nobody, EVER, noticed. Because EAPI is being reused. This is the right way to go, because it is simple, elegant, more flexible and easier to understand. Wanting to keep a bad thing just for keeping makes no sense.

i'm against this patch.

@bu5hm4n wait a bit : it seems that mallinfo in libmalloc should not be used, i am waiting some confirmation

remove useless link flag

pie is not supported by the solaris linker

sunos build : add mallinfo() check

move socket dep to eina_deps

or alloca() ? Normally, it is correctly declares (see eina_alloca.h)

In D11939#228210, @felipealmeida wrote:

Exactly. Another special case. What do we want to accomplish with this added complexity? Is EFL supposed to be multi-platform or not? Is Windows a platform that EFL is supposed to run on ? If it is not supposed to run in WIndows, then I'll glad fork it for what we need. But go through with undef/def of symbols which means ABSOLUTELLY different things in the same translation unit is completely bizarre.

#if defined EFL_ONE_BUILD || defined EFL_EINA_BUILD

@felipealmeida that's what i did in my first definition of EAPI a long time ago : i used EFL_EINA_BUILD in EAPI definition and I added -DEFL_EINA_BUILD when compiling the lib, that's all

note that there is a company which is actually trying to help the windows port, using the microsoft compiler, so please don't consider that only gcc will be used

In D11939#227620, @jptiz wrote:

Hum, right. Does it apply for the "upper" libraries? i.e. ecore_something.h including Eina.h? I.e. #include Eina.h should come before any #include ecore_<...>.h, right?

but eina_types.h must not be inluded by any program, never. It's Eina.h that must be included, always. eina_types.h is included explicitely only in eina source code. Also the order of all the eina_.h is important, and including for example, evil_private.h in between eina_*.h is just wrong. evil_private.h MUST be included before any eina header file used in eina source code.

why not letting EAPI in eina_types.h ? I don't think that there is any benefit

ok for clang format

this should also break everything not linux, as SCHED_IDLE is specific to linux

on Windows, see

https://git.enlightenment.org/core/efl.git/commit/src/lib/eina?id=a555fbf7693338d8b545d89f87a45852958a2166

missing guards, see D11873

i didn't touch those meson files as they are not used on Windows :-)

what about setting EFL_BUILD only if subproject is mod or lib ? it seems more logical to set it when needed, not unset it when it's not needed