On Sat, 12 Jan 2013 09:26:13 +0100 Adrien Nader <adr...@notk.org> said:
> 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. last time i ran elementary under wine: 1. font all missing 2. window kept moving down the screen by 1 titlebar height each time it .. rendered? or mouse entered? i dont remember... vincent reported that on windows it was fine - but not under wine. 3. build times i dont think are a problem... we will have the ram and cpu power to throw at it. yes - cross-build on linux is faster. we should use that, BUT we should ALSO test builds on windows and EXECUTION/display on a real windows install regardless. we don't NEED a vm to do that on the server though.. but we need windows install(s) somewhere. and if its not automated it'll get missed. we can do cross-builds of each revision BUT limit "windows vm builds" to every N revisions or once per week or something... :) -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
