Hi Tom & Cedric,

On 6 January 2016 at 01:01, Tom Hacohen <[email protected]> wrote:

> Hey,
>
> ABI report generation is failing due to issues with Ector. I think I can
> hack around them for the purpose of the report, but these are real
> issues that need fixing./
>

Thanks for the report.


> The first obvious failure was the ector gl headers not being shipped.
> This sounds like internal engine stuff to me, are they even supposed to
> be shipped? I added a few headers to the list of installed headers
> because Ector_Gl.h is shipped, but I'm not even sure this one should be
> there.
>
> Even worse though is the fact that ector_surface.h is shipped and
> depends on ector_buffer.h which is intentionally not shipped (put in
> EXTRA_DIST).


Not a conscious choice on my part.
ector_buffer belongs to the rest of the headers, wherever they go.


> I don't know what to do with that. Should ector_surface.h
> not be shipped? Should ector_buffer.h be? Should something else happen
> there?
>
> Please, someone who knows this code (cedric?) fix it.
>

I don't think any Ector APIs should be "public".
This means no headers should be installed.

evas_ector_buffer.h also shouldn't be installed.

Currently Ector.h is protected by EFL_BETA_API_SUPPORT while the others
(Ector_GL, Ector_Cairo, ...) are not, but they should be.
Eventually Ector may become stable, but at this moment it clearly is not
meant to be used outside of Evas.

Cedric, what do you think?

-- 
Jean-Philippe André
------------------------------------------------------------------------------
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to