Re: [E-devel] EFL cross compilation for Windows

[Carsten H. (T. R. <ra...@ra...>]

On Wed, 26 Oct 2016 20:50:40 +0200 Adrien Nader <ad...@no...> said:

> 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. :) 

whenever people ask/mention efl and windows i always point them to
winbuilds.org and say "adrien does this - he's around. poke him" :)
 but that seems 

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    ra...@ra...