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 :))

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

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.

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 /

In D12021#229371, @vtorri wrote:

more a coding convention

In D12021#229369, @vtorri wrote:

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

In D11994#228967, @bu5hm4n wrote:

1 / 2 / 3 / 4: fine for me.
We recently bumped min version to 0.50 so 5 & 7 Should hopefully work without issues.

Looks good :)

Ok, I agree that the current EAPI usage is sort of error-prone. I'm closing this and let it for further discussion in a later patch with Felipe's proposal.

Set symbols in config.h

Change EAPI definition where it is already defined.

In D11939#227645, @bu5hm4n wrote:

I have to say that i do not like eina_api.h. Why not just altering the current EAPI defitionions ?

In D11939#227619, @vtorri wrote:

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.

In D11939#227611, @vtorri wrote:

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

In D11939#227611, @vtorri wrote:

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

Getting the patch straight from devs/stefan/efl-dll works pretty fine and passes tests. :)

Passing tests :)

I applyed the patch locally here (against updated master), but it fails with the same error @stefan_schmidt had.

I would love to see clang-format for that, but it doesn't seem to support it well (https://clang.llvm.org/docs/ClangFormatStyleOptions.html). I tried some small tests but didn't get good results (e.g. it interprets # as preprocessor directives, moving comments to start of line and breaking too long comments with \).

Figured out what @bu5hm4n was saying, I think.

Seems reasonable and apparently nothing broke here.

Works and passes tests here (in Linux).

In D11771#224609, @stefan_schmidt wrote:

Marked it as false positive now.

@jptiz are you looking at the other cxx Coverity issues as well?

In T8620#150911, @bu5hm4n wrote:

Maybe try to build efl with asan enabled, maybe that is causing it to crash ? (meson configure -Db_sanitize=address)

In T8620#150908, @zmike wrote:

Probably want to valgrind that, the errors printed here aren't related.

You mean this?

True, my EFL was out of date!

Oh, okay, found the neovim issue: the file is actually called "nvim.desktop", not "neovim.desktop", that's why. My eyes just didn't catch it at first.

About the purpose: understood, gonna update the main post.

Add a test-case.

Add tests.

Add tests.

Just to add some (possibly) useful info:

Got the following build error for efl_mono.dll:

Passes tests and has pretty nice refactors.

Fix mess with arc: considering only last commit, not the entire dependencies.

Add managed name to exception message and simplify ifs.

Indexers have been reverted as not good practices for our use-cases (as stated in D11114).

@felipealmeida So, I've found rEFL581bec9598943cc9274dfe7db1a73a4c878c3cdd, which makes struct immutable because of C# recommendations (and there's the reasoning I was looking for, too). Should we propose to make EO structs generate classes instead, then? Where could I read/who to talk about if it would or not go against the idea of EO structs?

Oops, just realized actually structs don't have properties (https://www.enlightenment.org/contrib/docs/eo). Maybe changing an eo-struct would require creating a new one with modified values, letting mutability only to classes?

As far as I can see from struct_definition.hh, fields are intentionally read-only (don't know the reason, tho), while properties may be writable. Should we change that rule and add a set for them, then? Where could I find the reasoning about who should be read-only, etc.?

Does this commit resolve this task? Or is there something missing?

Looks good to me :)

Updated diff title to describe better what does it change.

Update to reflect changes from 581bec9598943cc9274dfe7db1a73a4c878c3cdd.

In D11190#212430, @segfaultxavi wrote:

The accessor<string> part is generating invalid C# code:

src/bindings/mono/efl_ui_dnd.eo.cs(438,69): error CS0029: Cannot implicitly convert type `System.Collections.Generic.IEnumerable<string>' to `System.IntPtr'
src/bindings/mono/efl_ui_dnd.eo.cs(448,69): error CS0029: Cannot implicitly convert type `System.IntPtr' to `System.Collections.Generic.IEnumerable<string>'

As far as I can see, this is the first time we try to use this in our API.
Calling in the C# people... @felipealmeida, @jptiz, any idea what is happening?

Use current indent level instead of arbitrary level 2.