Re: [E-devel] evil status and removing API in Evil
Hello On Fri, Mar 22, 2019 at 5:40 PM Michael Blumenkrantz wrote: > > This seems reasonable to me at a glance. Would it be worthwhile to stop > shipping the Evil.h header and make this exclusively an internal API for the > future? Unfortunately, it is not possible. For 2 reasons : 1) snprintf (defined in Evil) is used in an inlined header (eina_inline_slice.x iirc). This can be solved by defining directly snprintf in these inlined functions but it's not very nice imho. Note that snprintf is defined several times in the EFL code... 2) some Unix types used in Ecore.h that I define in Evil.h. Maybe in EFL 2.0 we can clean that. anyway, I plan to at least write an evil_private.h used in EFL code and let in Evil.h as few api as needed. I'll provide some diff for these 3 modifications i have proposed. thank you Vincent > On Fri, 22 Mar 2019 09:26:26 +0100 > Vincent Torri wrote: > > > Hello > > > > I would like to modify the API of Evil. The reason i want to do it is > > that i do not consider the Windows port stable enough (no CI, too much > > build errors appears here and there, DnD API not stable, etc...). And > > also, my big mistake is having made Evil a public API (or at least > > i've exported too much symbols). > > > > I would like to do the following changes : > > > > 1) remove mkstemp : mingw-w64 is currently defining it > > > > 2) removing regex implementation : ewpi is adding one implementation > > (the one in musllic library) and the one in evil is a very old one > > > > 3) removing fnmatch implementation : same as 2), it is provided by musl. > > > > note that would mean, for 2) and 3) aditional work in the build system > > (we must then link against libregex.dll on Windows, not a big deal) > > > > I would like to know if this proposal can be accepted > > > > thank you > > > > Vincent Torri > > > > > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evil status and removing API in Evil
This seems reasonable to me at a glance. Would it be worthwhile to stop shipping the Evil.h header and make this exclusively an internal API for the future? On Fri, 22 Mar 2019 09:26:26 +0100 Vincent Torri wrote: > Hello > > I would like to modify the API of Evil. The reason i want to do it is > that i do not consider the Windows port stable enough (no CI, too much > build errors appears here and there, DnD API not stable, etc...). And > also, my big mistake is having made Evil a public API (or at least > i've exported too much symbols). > > I would like to do the following changes : > > 1) remove mkstemp : mingw-w64 is currently defining it > > 2) removing regex implementation : ewpi is adding one implementation > (the one in musllic library) and the one in evil is a very old one > > 3) removing fnmatch implementation : same as 2), it is provided by musl. > > note that would mean, for 2) and 3) aditional work in the build system > (we must then link against libregex.dll on Windows, not a big deal) > > I would like to know if this proposal can be accepted > > thank you > > Vincent Torri > > > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] evil status and removing API in Evil
Hello I would like to modify the API of Evil. The reason i want to do it is that i do not consider the Windows port stable enough (no CI, too much build errors appears here and there, DnD API not stable, etc...). And also, my big mistake is having made Evil a public API (or at least i've exported too much symbols). I would like to do the following changes : 1) remove mkstemp : mingw-w64 is currently defining it 2) removing regex implementation : ewpi is adding one implementation (the one in musllic library) and the one in evil is a very old one 3) removing fnmatch implementation : same as 2), it is provided by musl. note that would mean, for 2) and 3) aditional work in the build system (we must then link against libregex.dll on Windows, not a big deal) I would like to know if this proposal can be accepted thank you Vincent Torri ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
