Page MenuHomePhabricator

Please install engine headers again
Closed, WontfixPublic


Prior to the EFL library merge, engine headers were installed. Sometime between now and then, they were removed. This has broken downstream software like exactimage [1]. It seems these should be installed again, see conversation at [2].



Can you explain why you need it as it is a way for us to avoid API/ABI compatibility problem. Also they have always been optional.

Basically I would like to know which backend you use. I am guessing buffer, but I haven't looked at your code.

exactimage can use software X11 and GL X11. It worked with 1.8, but fails to build against 1.20.

jpeg added a comment.EditedOct 18 2017, 11:35 PM

URL: ubuntu. This package is not trivial to compile...

jpeg added a comment.Oct 18 2017, 11:57 PM

Damn... this is... old. The code is using evas engine and X11 directly, no ecore, nothing.
Honestly I'm not sure it's even possible to make it work with 1.20. Installing the headers will give us errors:

edisplay/ error: ‘struct _Evas_Engine_Info_Software_X11::<unnamed>’ has no member named ‘display’
       einfo->info.display = dpy;
jpeg added a comment.Oct 19 2017, 12:10 AM

The latest version I could find, at:
I didn't test SVN.
This doesn't compile, add the following patch:

This will still fail to compile, even if the headers are installed, because they changed fundamentally (multi output).

Was this api considered stable prior to the merge? If not, this isn't worth any more time.

If it was, as a distro packager, I'd like to avoid breaking software that was using stable apis. But it sounds like a fix might not be possible in this case. I doubt it is worth worse breakage elsewhere.

Yes, they were optional and there wasn't a good reason to use them directly. If you point me at the code using it,I should be able to update it easily to use ecore evas API that was already there prior to the merge.

jpeg added a comment.Oct 19 2017, 9:41 PM

I believe the only real solution we have here is to modify exactimage itself. That will require quite some work, but I guess we may even be able to use an elm_win to do the job, unless something very special needs to be done.

I don't know of an upstream version control repo, but the tarball is here:

It's not my code, so I'm not familiar with it. Not sure it's really worth your time to work on this, but I'd be happy to test & pass on a patch if you're ever so inclined.

zmike added a subscriber: zmike.Jan 14 2019, 11:10 AM

So are we doing something with this?

i think we aren't - the implication is code should use the higher level api wrappers. we had to expose these structs because we used to have efl broken up and had to expose an api from one lib to another... :)

So this is a won't fix ?

raster closed this task as Wontfix.Mar 30 2019, 6:56 AM