On Fri, Jan 11, 2013, Carsten Haitzler wrote: > On Fri, 11 Jan 2013 13:59:48 +1000 David Seikel <onef...@gmail.com> said: > > > On Fri, 11 Jan 2013 11:51:04 +0900 Cedric BAIL <cedric.b...@free.fr> > > wrote: > > > > > On Fri, Jan 11, 2013 at 11:46 AM, Carsten Haitzler > > > <ras...@rasterman.com> wrote: > > > > On Fri, 11 Jan 2013 09:46:42 +0900 Cedric BAIL > > > > <cedric.b...@free.fr> said: > > > >> On Fri, Jan 11, 2013 at 9:26 AM, Carsten Haitzler > > > >> <ras...@rasterman.com> wrote: > > > >> > On Fri, 11 Jan 2013 09:08:20 +0900 Cedric BAIL > > > >> > <cedric.b...@free.fr> said: > > > >> >> On Fri, Jan 11, 2013 at 7:51 AM, Nicolas Aguirre > > > >> >> <aguirre.nico...@gmail.com> wrote: > > > >> >> > After lucas commit, i tried to build EFL merge for win32. > > > >> >> > > > > >> >> > i configure with : ./configure --prefix=$MINGW_PREFIX > > > >> >> > --host=$TARGET --disable-static --with-tests=none > > > >> >> > --with-crypto=gnutls --disable-gstreamer > > > >> >> > --disable-pulseaudio --disable-audio --disable-physics > > > >> >> > > > > >> >> > --disable-gstreamer option does't work at all, it's ignored, > > > >> >> > attached a patch which fix this issue. > > > >> >> > > > > >> >> > The next issue is that the configure try to check for eeze, > > > >> >> > but eeze is a linux only package, it's a non sense for > > > >> >> > windows or macos. So how to remove eeze from the build ? > > > >> >> > It could be a good option to add a --disable-eeze option in > > > >> >> > the configure ? what you think about it ? > > > >> >> > > > >> >> Obviously, yes. > > > >> >> > > > >> >> I think we really need to setup a buildbot for mingw as the > > > >> >> last serie of patch prove that nobody did test it at all and > > > >> >> made change that are likely to break it. > > > >> > > > > >> > first... need to make a qemu vm for windows... and that means a > > > >> > windows licence/copy at a minimum. we should test a real build > > > >> > ON windows ... as opposed to a cross-compile. here's the > > > >> > question. windows xp, vista, 7 or 8? sure - in theory we should > > > >> > have all. in theory if we use xp... then what we build > > > >> > binary-wise AND the build itself should work on later versions > > > >> > too... > > > >> > > > >> At this point, just automated building will be a huge step > > > >> forward... > > > > > > > > but we can't build on windows.. without a windows... install ... to > > > > build on. :P > > > > > > Cross compilation is faster as far as I know for windows :-) > > > > Vincent's Windows stuff was made to cross compile with mingw under > > Linux. That's the main delivery method he used. So no need for a > > Windows license to compile it. And as Cedric said, at least that means > > we can make sure compiling is not broken. Leave the result easily > > downloaded, and I'm sure people will download it to test it on their > > expensive Windows installs. > > but we can't make sure that compiling *ON* windows is not broken. we also > can't > verify if it runs properly or not (missing symbols, modules simply not loading > at all etc.).
Don't worry about missing symbols, there can be no undefined symbols in DLLs (that's in the design of the PE loader). Anyway, I get your point and I agree that's a goal but it's much more work. However it is *cross*-compilation which is way cleaner and nicer than compiling from something on windows. Various thoughts as bullet points: - building from cygwin to windows (not to cygwin) is cross-compilation - building from msys to windows (not to msys) is cross-compilation - msys is a big ugly hack (a fork of cygwin and a never-upstreamed fork of gcc 2.95 or 2.96 to add a specific target) - msys is a bastard in the first meaning of the name: it's a tentative mix of windows and posix, a guess of what comes from which, goes where and how it should be translated - buildbots on msys and cygwin will probably never be able to handle the load because of how slow they will be (iirc it took Vincent 10 times longer to build elementary from msys) and a ccache would probably make things worse - wine is working well enough to provide a good testing platform (I'm not saying that would replace tests on windows however) - vnc and rdesktop will have a much bigger impact on the rendering than wine - you can perfectly build on linux, test on windows and for that you can easily use the evaluation editions of windows; they have limitations but should be enough/perfect for tests tl;dr: msys and cygwin are cross-compilation anyway, both will make building too slow, msys is crap, wine is better than you seem to think and will make it possible to check the rendering and testing could be done through VMs with eval versions of windows. -- Adrien Nader ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
