Better variable naming for deps. Organizing a coulpe of #ifdefs.

Let efreet enabled by default.

In D12151#232370, @cedric wrote:

This is really not ideal. A few feature will be broken when porting an EFL apps that use eio/efl_io_model/filemanager to Windows. Isn't it possible to get some of the feature of efreet to work on the platform you are working on?

Remove unnecessary message(file) (which was intended for temporary debugging)

This ticket has been closed as spam because it lacks a description. If this ticket is not spam, please reopen it after adding a description.

This is ready for review again.

Add a small comment about response_file test.

Actually execute eolian_gen in _eolian_gen_execute_rsp function.

In D12118#231690, @vtorri wrote:

In D12118#231689, @jptiz wrote:

In D12118#231687, @vtorri wrote:

also see https://docs.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shgetfileinfoa

the 'return value' section.

I test only if the result is 0 or not.

Ooooh right. So in that case, it would be necessary to split Hi and Lo bits and compare them separately?

why ?

if it's != 0, then I consider (according to the doc) Windows application, MS-DOS .exe or .com files and Console application or .bat file

so all of them

In D12118#231687, @vtorri wrote:

also see https://docs.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shgetfileinfoa

the 'return value' section.

I test only if the result is 0 or not.

In D12118#231686, @vtorri wrote:

strange because i've tested on a .bat explicitely. Here the problem is a .sh which is not supported outside a unix shell

This patch makes sense for me. Also, since you looked into this part of EFL, I would like to point out: apparently Windows considers only .exe files to be executables (neither .bat or .ps1 or any other file is), so even with SHGetFileInfo, tests like this will fail (as it does even with this patch). I'll open a phab task for this later.

Looking good

In D12111#231596, @lucas wrote:

In D12111#231595, @jptiz wrote:

In D12111#231593, @vtorri wrote:

see D12112

Oh right right. I should apply that before this one?

I think the order doesn't matter. But as HAVE_GETTIMEOFDAY was not defined you will need both.

In D12111#231593, @vtorri wrote:

see D12112

I've got an error in src/lib/ecore/ecore_time.c:

Going to add a response-file test.

Fix issue with rsp file path having the same size as final command-line string.

Forgot to add int -> size_t changes.

In D12105#231474, @bu5hm4n wrote:

Just my two cents: I think the tests should unconditionally run with the respones files, and not only if PATH_MAX is too small, this way we can ensure that the respone file is tested on any maschine that runs the tests.

Fix wrong cherry-pick resolution (i.e. use options again instead of type, which was from another commit that is not on upstream).

In D12105#231471, @stefan_schmidt wrote:

Applies now, but shows errors when building:

[1/3252] Compiling C object 'src/bin/eolian/70b716a@@eolian_gen@exe/main.c.o'
../src/bin/eolian/main.c: In function ‘_read_options_from_response_file’:
../src/bin/eolian/main.c:524:22: warning: comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Wsign-compare]
  524 |    for (int i = 0; i < file_length; ++i)
      |                      ^
../src/bin/eolian/main.c:543:22: warning: comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Wsign-compare]
  543 |    for (int i = 0; i < file_length; ++i)
      |                      ^
../src/bin/eolian/main.c:548:23: warning: comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Wsign-compare]
  548 |              while (i < file_length && contents[i] == '\0')
      |                       ^
../src/bin/eolian/main.c:553:20: warning: comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Wsign-compare]
  553 |              if (i >= file_length)
      |                    ^~

In D12105#231460, @stefan_schmidt wrote:

This does not apply to latest HEAD anymore, please rebase.

Rebase to correct commit

Looks good to me.

Inline options initialization.

Fixed INVALID_FILE_ATTRIBUTES in the right place.

Fix CmdLineOptions case to Cmd_Line_Options and undo
INVALID_FILE_ATTRIBUTES change (which will be splitted into another patch).

Small enhancement for -r's description in usage

Remove unused variable FILE *fp.

Change diff to actually remove OS version check completely.

In D12095#231148, @vtorri wrote:

actually, in 2020, i prefer dropping this test... faster evil_init

Reorder headers in order to have FORCEINLINE defined in versionhelpers.h

Working on it.

@vtorri: I did some stub just to let this task open (and not ending up forgetting about it later haha), but there are some infos I don't have (the ones I let with a "?"). If you could provide them (and check if I understood the issue correctly), I would appreciate :)

Move test_file declaration to function's beginning.

In D12064#230507, @stefan_schmidt wrote:

I am landing this, but you should look into fixing your git commit author

Lucas <Coquinho@users.noreply.github.com>

Missing last name and wrong email.

Fixed a typo on Querry.

No more evil_second.

I'll try working on a couple issues this week :)

Put back a call to QueryPerformanceFrequency.

• Remove st, second and _evil_time_second;
• Remove unnecessary if (QueryPerformanceFrequency(...)).

Ok, I think that's it for this patch. Should I squash the commits it or will it be squashed by who lands the patch?

Removed 6 and 8 from this patch, so we stick with just:

In D11994#228967, @bu5hm4n wrote:

6: Mhm, -Wall does not find its way into the cflags of the build.ninja file, even if the default warning is 3. That should be fixed.

Ok, took my time to think of the arguments here. So let me reorganize the ideas...

My mind just messed up some phrases in the last comment. Edited to make more sense :^D.

In T8761#153094, @bu5hm4n wrote:

First Half of the issue

I think you can just remove the _dep prefix from these 4 vars ... no big deal, there is really no thought behind that scheme, just make sure the names do not collide :)

In D12034#229621, @vtorri wrote:

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 ?

Readd regexp on non-windows environments.

Replace explicit dependency('zlib') with zlib variable.

Since D12031 has landed, I think this one can be closed.

Add back the accidentally-removed DLL_EXPORT=1.

In D11994#229536, @bu5hm4n wrote:

With these two comments, then: should I split 6 and 8 into two other patches? For 6 because we can track this in an isolated patch, and for 8 because of possible opinion divergence.

Sounds good :) (If getting out 8 is too much work, i dont have a issue with first merging that if the rest of the stuff is coming in a next patch :))