On Wed, Oct 26, 2016, Andrii Kroitor wrote: > Hello, Adrien. > > It's nice to meet you here. > > On 26.10.16 08:50, Adrien Nader wrote: > > [...] > >>> Should these packages be updated and uploaded manually? > >> If the path with win builds does not work out we could host the windows > >> binaries next to our source tarballs. Only for releases thought. > > Writing and improving the package manager's GUI took time off the > > packaging itself and has delayed the current release a lot. > Could you share some estimation on release date, please? Have you changed > or updated something in cross builds part? > I have tried to setup win-builds cross compilation on few different > Linux systems, > but it was unsuccessful. Are your current scripts in public access > somewhere? > > But that actually doesn't matter much. It's supposed to be possible to > > base on win-builds and build other versions or other packages and I > > don't see why that couldn't apply to the EFLs. > > > > However I'm not sure I understand some of things done in that git > > repository. I've only taken a cursory look at it and can't comment much > > but I've been more than surprised to see a pthread.h file copied there > > and that it came from pthreads-win32 which, I think(*), is > > ABI-incompatible while winpthreasd doesn't have that issue (everyone and > > their mothers assume pthread_t is an int like on linux). > > > > (*) maybe I've fixed the only occurrence of it a couple years ago, or > > maybe not, I don't know anymore, but somehow I doubt it > That file came from winpthreads-v3.3.0-2-x86_64-w64-mingw32.txz package > from winbuilds. > I've only added one explicit cast to bypass compilation error of > upstream EFL. > Problem is with pthread_cleanup_pop macro: > > #define pthread_cleanup_pop(E)\ > (*pthread_getclean() = _pthread_cup.next, > (E?_pthread_cup.func((pthread_once_t *)_pthread_cup.arg):0));} > > It works fine in C code, but in case of C++ last 0 should be casted to > (void)
My issue with that file is that I understood it came from pthreads-win32 and not winpthreads. If that's not the case, then forget about this. Also the issue you mention is definitely valid and ahs actually been fixed recently in mingw-w64 upstream. That said such changes are better handled with patches to the corresponding component directly, especially since it's a small component which builds quickly. However I cannot say that win-builds has made such patching easy so far so I understand that you took the easier route. > > That said, the priorities in win-builds now are to provide a better > > integration with fetching sources from git, iron out the bugs and > > current limitations, and release. > You're doing awesome job. Thank you :) Thanks, still a fair bit to do however. :) -- Adrien Nader ------------------------------------------------------------------------------ The Command Line: Reinvented for Modern Developers Did the resurgence of CLI tooling catch you by surprise? Reconnect with the command line and become more productive. Learn the new .NET and ASP.NET CLI. Get your free copy! http://sdm.link/telerik _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
