whynotboth.jpg

No, functions need to be there.

Or actually the block should be removed.

see D6363

@vtorri I would not wait on a reply for this; if you are able to test locally then please try that, otherwise if you think this patch will resolve it then you can just submit it normally with arc.

In D6263#107161, @zmike wrote:

I recall having an issue like this too recently when I was doing some Windows work; is this a PATH problem or ?

Disabling this seems bad since it will cause all eldbus tests to fail...

I recall having an issue like this too recently when I was doing some Windows work; is this a PATH problem or ?

that is the problem of Ecore.h relying on unix types... It is too late to change Ecore.h, unfortunately, maybe for EFL 2.0 we can change this.

In D5518#94662, @cedric wrote:

I would expect that { 0 } work ok everywhere else to ? I do prefer to have it fixed on the declaration of EINA_VALUE_EMPTY as it will limit the likelyness of future breakage here.

I would expect that { 0 } work ok everywhere else to ? I do prefer to have it fixed on the declaration of EINA_VALUE_EMPTY as it will limit the likelyness of future breakage here.

In D5518#94539, @jpeg wrote:

This line should be changed, instead, I think:

#define EINA_VALUE_EMPTY ((Eina_Value){ NULL, { { 0, 0, 0, 0, 0, 0, 0, 0 } } })

#if (defined GNUC) && (GNUC <= 4)

This line should be changed, instead, I think:

#define EINA_VALUE_EMPTY ((Eina_Value){ NULL, { { 0, 0, 0, 0, 0, 0, 0, 0 } } })

Build has FAILED

how can I test itwithout edje patch ? is there a test somewhere ?

That looks better to me (the public headers don't change based on internal/platform config), but as I mentioned in another patch... I don't think exposing WSAPI or even PULSE in the public headers is good - especially as separate classes and in our future eo based api's because we do try and be portable. there can be rare reasons to expose a platform specific api (because you may need to glue in platform specific data/objects/types) sometimes, but this here is not the case. there just should be a single portable class with portable methods (and maybe feature detection if needed to know if some feature in the api can work or not on the target system).