Page MenuHomePhabricator

windows: headers are messed up
Closed, ResolvedPublic


I'm trying to use efl from visual studio.
I have cross compiled efl for win64, so there are all dll's and dll.a files, includes etc.
Here is a simple ecore example that I'm trying to compile:

#include <iostream>
#include <thread>

#include <Ecore.h>
using namespace std;

static Eina_Bool
_stop(void *data)
   cout << "stop" << endl;

static Eina_Bool
_countdown(void *data)
   static int i = 10;
   cout << i-- << endl;
   return 1;

void t1()
   ecore_timer_add(1, _countdown, NULL);
   ecore_timer_add(10, _stop, NULL);

int main()
   thread a1(t1);
   return 0;

This fails because of Ecore.h that only for visual studio includes Evil:

#ifdef _MSC_VER
# include <Evil.h>

that surprisingly expects <sys/types.h> to have for example pid_t defined. So header that is included only by VS compiler relays on things that are missing in that toolchain.
In my example I can easily bypass this issue by dirty hack:

#include <Ecore.h>

with needed thing directly:

#define Eina_Bool bool

extern "C" {
	__declspec(dllimport) void ecore_main_loop_begin(void);
	__declspec(dllimport) void ecore_main_loop_quit(void);
	__declspec(dllimport) int ecore_init(void);
	__declspec(dllimport) int ecore_shutdown(void);

	typedef Eina_Bool(*Ecore_Task_Cb)(void *data);
	__declspec(dllimport) void *ecore_timer_add(double in, Ecore_Task_Cb func, const void *data);

But this would be painful to write and to support for anything bigger.

I'm not asking for efl to be compilable with VS.
We have working library on Windows, but with broken headers.
So we should either fix this or make at least public headers much simpler and cleaner, without this cross-include mess.

an.kroitor added subscribers: efl, Windows.
rimmed added a subscriber: rimmed.Feb 23 2017, 8:57 PM
bu5hm4n triaged this task as High priority.Jun 11 2018, 2:03 AM
bu5hm4n assigned this task to vtorri.
billiob removed a subscriber: efl.Jun 11 2018, 2:07 AM
vtorri added a comment.EditedJun 11 2018, 2:37 AM

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.

note that i am planning to separate Evil.h into 2 parts :
Evil.h : for symbols and types needed by the EFL API.
evil_private.h : for symbols needed in the source code of the EFL

note also that Ecore_Common.h also expects pid_t, it's not only Evil (because of fcntl)

now, can you add this code in Evil.h, for example after the definition of gid_t (around line 108) :

#ifdef _MSC_VER
# ifdef _WIN64
typedef __int64 pid_t;
# else
typedef int pid_t;
# endif

and see if it fixes the problem ?

edit : if it works, i'll provide a patch

zmike edited projects, added Restricted Project; removed efl.Jun 11 2018, 6:54 AM
zmike edited projects, added efl; removed Restricted Project.Jun 11 2018, 8:57 AM
bu5hm4n edited projects, added Restricted Project; removed efl.Jun 11 2018, 10:44 AM
zmike added a subscriber: zmike.Jun 20 2018, 6:13 AM

@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.