Re: [E-devel] efl merge and win32
Hello. On 12/02/13 01:14, Cedric BAIL wrote: > Hello, > > On Mon, Feb 11, 2013 at 10:56 PM, Stefan Schmidt > wrote: >> Hello. >> >> On 11/02/13 13:53, Stefan Schmidt wrote: >>> >>> I fixed up the most bogus things and that part builds now. Next was >>> eina_mmap failing due to stuff no available on Windows. Here I lost >>> motivation. >> >> If anybody has interest in this: >> >> CC lib/eina/lib_eina_libeina_la-eina_accessor.lo >> CC lib/eina/lib_eina_libeina_la-eina_array.lo >> CC lib/eina/lib_eina_libeina_la-eina_benchmark.lo >> CC lib/eina/lib_eina_libeina_la-eina_binbuf.lo >> CC lib/eina/lib_eina_libeina_la-eina_binshare.lo >> CC lib/eina/lib_eina_libeina_la-eina_convert.lo >> CC lib/eina/lib_eina_libeina_la-eina_counter.lo >> CC lib/eina/lib_eina_libeina_la-eina_cpu.lo >> CC lib/eina/lib_eina_libeina_la-eina_error.lo >> CC lib/eina/lib_eina_libeina_la-eina_fp.lo >> CC lib/eina/lib_eina_libeina_la-eina_hamster.lo >> CC lib/eina/lib_eina_libeina_la-eina_hash.lo >> CC lib/eina/lib_eina_libeina_la-eina_inarray.lo >> CC lib/eina/lib_eina_libeina_la-eina_inlist.lo >> CC lib/eina/lib_eina_libeina_la-eina_iterator.lo >> CC lib/eina/lib_eina_libeina_la-eina_lalloc.lo >> CC lib/eina/lib_eina_libeina_la-eina_list.lo >> CC lib/eina/lib_eina_libeina_la-eina_log.lo >> CC lib/eina/lib_eina_libeina_la-eina_magic.lo >> CC lib/eina/lib_eina_libeina_la-eina_main.lo >> lib/eina/eina_main.c: In function 'eina_init': >> lib/eina/eina_main.c:253:4: warning: implicit declaration of function >> 'time' [-Wimplicit-function-declaration] >> CC lib/eina/lib_eina_libeina_la-eina_matrixsparse.lo >> CC lib/eina/lib_eina_libeina_la-eina_mempool.lo >> CC lib/eina/lib_eina_libeina_la-eina_mmap.lo >> lib/eina/eina_mmap.c:71:24: error: unknown type name 'siginfo_t' >> lib/eina/eina_mmap.c: In function 'eina_mmap_safety_enabled_set': >> lib/eina/eina_mmap.c:133:27: error: storage size of 'sa' isn't known >> lib/eina/eina_mmap.c:154:14: warning: implicit declaration of function >> 'fcntl' [-Wimplicit-function-declaration] >> lib/eina/eina_mmap.c:154:48: error: 'F_GETFD' undeclared (first use in >> this function) >> lib/eina/eina_mmap.c:154:48: note: each undeclared identifier is >> reported only once for each function it appears in >> lib/eina/eina_mmap.c:155:23: error: 'FD_CLOEXEC' undeclared (first use >> in this function) >> lib/eina/eina_mmap.c:156:40: error: 'F_SETFD' undeclared (first use in >> this function) >> lib/eina/eina_mmap.c:161:27: error: '_eina_mmap_safe_sigbus' undeclared >> (first use in this function) >> lib/eina/eina_mmap.c:162:23: error: 'SA_RESTART' undeclared (first use >> in this function) >> lib/eina/eina_mmap.c:162:36: error: 'SA_SIGINFO' undeclared (first use >> in this function) >> lib/eina/eina_mmap.c:163:9: warning: implicit declaration of function >> 'sigemptyset' [-Wimplicit-function-declaration] >> lib/eina/eina_mmap.c:164:9: warning: implicit declaration of function >> 'sigaction' [-Wimplicit-function-declaration] >> lib/eina/eina_mmap.c:164:23: error: 'SIGBUS' undeclared (first use in >> this function) >> lib/eina/eina_mmap.c:133:27: warning: unused variable 'sa' >> [-Wunused-variable] >> make[4]: *** [lib/eina/lib_eina_libeina_la-eina_mmap.lo] Error 1 >> make[3]: *** [all-recursive] Error 1 >> make[2]: *** [all] Error 2 >> make[1]: *** [all-recursive] Error 1 >> make: *** [all] Error 2 > > There is apparently no windows implementation of > eina_mmap_safety_enabled_set (signal don't exist on windows). The idea > of this function is to setup a sigbus handler to detect access to > corrupted file with Eina_File. I have no idea how to detect that in > Windows land. For the moment I would say we should properly disable > the code. Now we only need someone with interest and motivation in fixing this. :) regards Stefan Schmidt -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl merge and win32
Hello, On Mon, Feb 11, 2013 at 10:56 PM, Stefan Schmidt wrote: > Hello. > > On 11/02/13 13:53, Stefan Schmidt wrote: >> >> I fixed up the most bogus things and that part builds now. Next was >> eina_mmap failing due to stuff no available on Windows. Here I lost >> motivation. > > If anybody has interest in this: > >CC lib/eina/lib_eina_libeina_la-eina_accessor.lo >CC lib/eina/lib_eina_libeina_la-eina_array.lo >CC lib/eina/lib_eina_libeina_la-eina_benchmark.lo >CC lib/eina/lib_eina_libeina_la-eina_binbuf.lo >CC lib/eina/lib_eina_libeina_la-eina_binshare.lo >CC lib/eina/lib_eina_libeina_la-eina_convert.lo >CC lib/eina/lib_eina_libeina_la-eina_counter.lo >CC lib/eina/lib_eina_libeina_la-eina_cpu.lo >CC lib/eina/lib_eina_libeina_la-eina_error.lo >CC lib/eina/lib_eina_libeina_la-eina_fp.lo >CC lib/eina/lib_eina_libeina_la-eina_hamster.lo >CC lib/eina/lib_eina_libeina_la-eina_hash.lo >CC lib/eina/lib_eina_libeina_la-eina_inarray.lo >CC lib/eina/lib_eina_libeina_la-eina_inlist.lo >CC lib/eina/lib_eina_libeina_la-eina_iterator.lo >CC lib/eina/lib_eina_libeina_la-eina_lalloc.lo >CC lib/eina/lib_eina_libeina_la-eina_list.lo >CC lib/eina/lib_eina_libeina_la-eina_log.lo >CC lib/eina/lib_eina_libeina_la-eina_magic.lo >CC lib/eina/lib_eina_libeina_la-eina_main.lo > lib/eina/eina_main.c: In function 'eina_init': > lib/eina/eina_main.c:253:4: warning: implicit declaration of function > 'time' [-Wimplicit-function-declaration] >CC lib/eina/lib_eina_libeina_la-eina_matrixsparse.lo >CC lib/eina/lib_eina_libeina_la-eina_mempool.lo >CC lib/eina/lib_eina_libeina_la-eina_mmap.lo > lib/eina/eina_mmap.c:71:24: error: unknown type name 'siginfo_t' > lib/eina/eina_mmap.c: In function 'eina_mmap_safety_enabled_set': > lib/eina/eina_mmap.c:133:27: error: storage size of 'sa' isn't known > lib/eina/eina_mmap.c:154:14: warning: implicit declaration of function > 'fcntl' [-Wimplicit-function-declaration] > lib/eina/eina_mmap.c:154:48: error: 'F_GETFD' undeclared (first use in > this function) > lib/eina/eina_mmap.c:154:48: note: each undeclared identifier is > reported only once for each function it appears in > lib/eina/eina_mmap.c:155:23: error: 'FD_CLOEXEC' undeclared (first use > in this function) > lib/eina/eina_mmap.c:156:40: error: 'F_SETFD' undeclared (first use in > this function) > lib/eina/eina_mmap.c:161:27: error: '_eina_mmap_safe_sigbus' undeclared > (first use in this function) > lib/eina/eina_mmap.c:162:23: error: 'SA_RESTART' undeclared (first use > in this function) > lib/eina/eina_mmap.c:162:36: error: 'SA_SIGINFO' undeclared (first use > in this function) > lib/eina/eina_mmap.c:163:9: warning: implicit declaration of function > 'sigemptyset' [-Wimplicit-function-declaration] > lib/eina/eina_mmap.c:164:9: warning: implicit declaration of function > 'sigaction' [-Wimplicit-function-declaration] > lib/eina/eina_mmap.c:164:23: error: 'SIGBUS' undeclared (first use in > this function) > lib/eina/eina_mmap.c:133:27: warning: unused variable 'sa' > [-Wunused-variable] > make[4]: *** [lib/eina/lib_eina_libeina_la-eina_mmap.lo] Error 1 > make[3]: *** [all-recursive] Error 1 > make[2]: *** [all] Error 2 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 There is apparently no windows implementation of eina_mmap_safety_enabled_set (signal don't exist on windows). The idea of this function is to setup a sigbus handler to detect access to corrupted file with Eina_File. I have no idea how to detect that in Windows land. For the moment I would say we should properly disable the code. -- Cedric BAIL -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl merge and win32
Hello. On 11/02/13 13:53, Stefan Schmidt wrote: > > I fixed up the most bogus things and that part builds now. Next was > eina_mmap failing due to stuff no available on Windows. Here I lost > motivation. If anybody has interest in this: CC lib/eina/lib_eina_libeina_la-eina_accessor.lo CC lib/eina/lib_eina_libeina_la-eina_array.lo CC lib/eina/lib_eina_libeina_la-eina_benchmark.lo CC lib/eina/lib_eina_libeina_la-eina_binbuf.lo CC lib/eina/lib_eina_libeina_la-eina_binshare.lo CC lib/eina/lib_eina_libeina_la-eina_convert.lo CC lib/eina/lib_eina_libeina_la-eina_counter.lo CC lib/eina/lib_eina_libeina_la-eina_cpu.lo CC lib/eina/lib_eina_libeina_la-eina_error.lo CC lib/eina/lib_eina_libeina_la-eina_fp.lo CC lib/eina/lib_eina_libeina_la-eina_hamster.lo CC lib/eina/lib_eina_libeina_la-eina_hash.lo CC lib/eina/lib_eina_libeina_la-eina_inarray.lo CC lib/eina/lib_eina_libeina_la-eina_inlist.lo CC lib/eina/lib_eina_libeina_la-eina_iterator.lo CC lib/eina/lib_eina_libeina_la-eina_lalloc.lo CC lib/eina/lib_eina_libeina_la-eina_list.lo CC lib/eina/lib_eina_libeina_la-eina_log.lo CC lib/eina/lib_eina_libeina_la-eina_magic.lo CC lib/eina/lib_eina_libeina_la-eina_main.lo lib/eina/eina_main.c: In function 'eina_init': lib/eina/eina_main.c:253:4: warning: implicit declaration of function 'time' [-Wimplicit-function-declaration] CC lib/eina/lib_eina_libeina_la-eina_matrixsparse.lo CC lib/eina/lib_eina_libeina_la-eina_mempool.lo CC lib/eina/lib_eina_libeina_la-eina_mmap.lo lib/eina/eina_mmap.c:71:24: error: unknown type name 'siginfo_t' lib/eina/eina_mmap.c: In function 'eina_mmap_safety_enabled_set': lib/eina/eina_mmap.c:133:27: error: storage size of 'sa' isn't known lib/eina/eina_mmap.c:154:14: warning: implicit declaration of function 'fcntl' [-Wimplicit-function-declaration] lib/eina/eina_mmap.c:154:48: error: 'F_GETFD' undeclared (first use in this function) lib/eina/eina_mmap.c:154:48: note: each undeclared identifier is reported only once for each function it appears in lib/eina/eina_mmap.c:155:23: error: 'FD_CLOEXEC' undeclared (first use in this function) lib/eina/eina_mmap.c:156:40: error: 'F_SETFD' undeclared (first use in this function) lib/eina/eina_mmap.c:161:27: error: '_eina_mmap_safe_sigbus' undeclared (first use in this function) lib/eina/eina_mmap.c:162:23: error: 'SA_RESTART' undeclared (first use in this function) lib/eina/eina_mmap.c:162:36: error: 'SA_SIGINFO' undeclared (first use in this function) lib/eina/eina_mmap.c:163:9: warning: implicit declaration of function 'sigemptyset' [-Wimplicit-function-declaration] lib/eina/eina_mmap.c:164:9: warning: implicit declaration of function 'sigaction' [-Wimplicit-function-declaration] lib/eina/eina_mmap.c:164:23: error: 'SIGBUS' undeclared (first use in this function) lib/eina/eina_mmap.c:133:27: warning: unused variable 'sa' [-Wunused-variable] make[4]: *** [lib/eina/lib_eina_libeina_la-eina_mmap.lo] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 regards Stefan Schmidt -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl merge and win32
Hello. On 11/01/13 07:21, Nicolas Aguirre wrote: > > I don't think so, cross compilation is better in any case, it's faster, > it's easy, and it's already present in almost all recent distributions. > It's also easy to build for 32 and 64 architecture with no extra cost. > About the windows version i don't know exatcly but i think you're right > with xp you should target all later versions. > > if you want to set up your machine for a build, Vincent did a build of all > dependencies > http://dev.enlightenment.fr/~doursse/efl_dep.zip it's for 32bits only > architecture. > Then you need to install mingw-w64 and gcc-mingw-w64-i686 > > Once unzip you only need to export few env vars : > > base=`pwd` > > export TARGET=i686-w64-mingw32 > export MINGW_PREFIX="$base/package/" I had to remove the packgae here as the zip unpacks without any package subdir for me. Only change I did to this. > export CPPFLAGS="-I$MINGW_PREFIX/include -I$MINGW_PREFIX/include/evil-1 > -I$MINGW_PREFIX/include/freetype2" > export CXXFLAGS="$CFLAGS" > export LDFLAGS="$LDFLAGS -L$MINGW_PREFIX/lib" > export PATH="$HOME/local/opt/mingw-w64-x86_32/bin:$MINGW_PREFIX/bin:$PATH" > export LD_LIBRARY_PATH="$MINGW_PREFIX/lib" > export PKG_CONFIG_PATH="$MINGW_PREFIX/lib/pkgconfig" > export PKG_CONFIG_LIBDIR="$MINGW_PREFIX/lib/pkgconfig" > > and then you can compile as usual efl : > > ./autogen.sh --prefix=$MINGW_PREFIX --host=$TARGET --disable-static Thanks for posting this. And major thanks to Vtorri to prepare all this. > That's all, it's really easy, and we don't need a real windows machine for > that. > Of course if you want automated it's better, but i don't think we have man > power for this. I did take a stab and integrating this into my local jenkins here today. I made some good progress but run out of motivation for more work. My configure line looks like this now: ./autogen.sh --prefix=$MINGW_PREFIX --host=$TARGET --disable-static --with-crypto=none --disable-physics --disable-gstreamer --with-tests=none --disable-fribidi --disable-image-loader-gif --disable-audio This is mainly due to workaround not having pre-compiled stuff for things like giflib, check, etc. After that I had to discover that someone was happy to do changes to the ecore_evas w32 engine without bothering to test or even simply check a variable is declared before assigning to it. :/ I fixed up the most bogus things and that part builds now. Next was eina_mmap failing due to stuff no available on Windows. Here I lost motivation. So yes, setting it up is easy and not that much trouble. If someone takes up on thsi I might even consider leaving this automated build for mingw in once I move our jenkins stuff out to e5. But it only makes sense if people want the build to work for w32. Personally I don't have any use of it. regards Stefan Schmidt -- Free Next-Gen Firewall Hardware Offer Buy your Sophos next-gen firewall before the end March 2013 and get the hardware for free! Learn more. http://p.sf.net/sfu/sophos-d2d-feb ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl merge and win32
On Wednesday, January 16, 2013, Carsten Haitzler wrote: > On Sat, 12 Jan 2013 09:26:13 +0100 Adrien Nader said: > > > On Fri, Jan 11, 2013, Carsten Haitzler wrote: > > > On Fri, 11 Jan 2013 13:59:48 +1000 David Seikel > said: > > > > > > > On Fri, 11 Jan 2013 11:51:04 +0900 Cedric BAIL > > > > wrote: > > > > > > > > > On Fri, Jan 11, 2013 at 11:46 AM, Carsten Haitzler > > > > > wrote: > > > > > > On Fri, 11 Jan 2013 09:46:42 +0900 Cedric BAIL > > > > > > said: > > > > > >> On Fri, Jan 11, 2013 at 9:26 AM, Carsten Haitzler > > > > > >> wrote: > > > > > >> > On Fri, 11 Jan 2013 09:08:20 +0900 Cedric BAIL > > > > > >> > said: > > > > > >> >> On Fri, Jan 11, 2013 at 7:51 AM, Nicolas Aguirre > > > > > >> >> 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 ilast 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... > > :) > Ahahah it would be so reasonable to have a windows port that we compile from Linux and test in wine! I could even call the x11 port and nobody would notice! ;-) Now seriously, we always lacked manpower to do the windows port. Now that Vincent left, the situation became worse. While I can install the mingw stuff and fix compilations, I'll not maintain it as I don't have time or interest. That said, if the windows support is to be kept I'd ask: - a maintainer that compiles and test at least every week. - a build bot that will work in the same way as Linux (integrated to our master) Otherwise it's fixing now to have it broken in the other day. :-( -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- 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_12
Re: [E-devel] efl merge and win32
On Sat, 12 Jan 2013 09:26:13 +0100 Adrien Nader said: > On Fri, Jan 11, 2013, Carsten Haitzler wrote: > > On Fri, 11 Jan 2013 13:59:48 +1000 David Seikel said: > > > > > On Fri, 11 Jan 2013 11:51:04 +0900 Cedric BAIL > > > wrote: > > > > > > > On Fri, Jan 11, 2013 at 11:46 AM, Carsten Haitzler > > > > wrote: > > > > > On Fri, 11 Jan 2013 09:46:42 +0900 Cedric BAIL > > > > > said: > > > > >> On Fri, Jan 11, 2013 at 9:26 AM, Carsten Haitzler > > > > >> wrote: > > > > >> > On Fri, 11 Jan 2013 09:08:20 +0900 Cedric BAIL > > > > >> > said: > > > > >> >> On Fri, Jan 11, 2013 at 7:51 AM, Nicolas Aguirre > > > > >> >> 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
Re: [E-devel] efl merge and win32
On Mon, Jan 14, 2013 at 12:03 PM, Cedric BAIL wrote: > On Mon, Jan 14, 2013 at 7:51 PM, Gustavo Sverzut Barbieri > wrote: >> On Mon, Jan 14, 2013 at 4:53 AM, Nicolas Aguirre >> wrote: >>> 2013/1/11 Gustavo Sverzut Barbieri On Fri, Jan 11, 2013 at 4:43 PM, Nicolas Aguirre wrote: modules/ecore_evas/engines/win32/modules_ecore_evas_engines_win32_module_la-ecore_evas_win32.lo > In file included from > modules/ecore_evas/engines/win32/ecore_evas_win32.c:19:0: error: > unterminated #ifdef > make[4]: *** > [modules/ecore_evas/engines/win32/modules_ecore_evas_engines_win32_module_la-ecore_evas_win32.lo] > Error 1 Flavio split ecore-evas engines out of ecore_evas itself, but seems he couldn't test with win32. It should be a matter of basing the fixes on other modules. Very likely these are just C errors that once fixed will work. > Anyway I'm away this week end, i will look into it next week. It's better if you can engage for couple of days into that. It will require lots of work and compilation rounds, not just the code changed, but the build system as well. Maybe some modules will have to be disabled, etc. >>> after ifdef correction (patch attached) i get a new kind of error, and i >>> fear it's related with all include you removed. >>> >>> Making all in src >>> make all-recursive >>> CC >>> modules/ecore_evas/engines/win32/modules_ecore_evas_engines_win32_module_la-ecore_evas_win32.lo >>> In file included from >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c:12:0: >>> ../src/lib/ecore_win32/Ecore_Win32.h:14:4: warning: #warning "You are using >>> a work in progress API. This API is not stable" [-Wcpp] >>> ../src/lib/ecore_win32/Ecore_Win32.h:15:4: warning: #warning "and is >>> subject to change. You use this at your own risk." [-Wcpp] >> >> ugh, this is annoying... what about if you patch Ecore_Win32.h to do >> like other libraries: >> >> #ifndef _ECORE_WIN32_API_IS_UNSTABLE_AND_I_KNOW_IT >> #warning "..."" >> #endif >> >> then define that for every user file in EFL. It does pollute too much >> and maybe that caused the confusion. See below. >> >> >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function >>> '_ecore_evas_win32_event_window_damage': >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c:258:3: warning: >>> #warning [ECORE] [WIN32] No Region code [-Wcpp] >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function >>> '_ecore_evas_win32_rotation_set': >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c:630:66: warning: unused >>> parameter 'resize' [-Wunused-parameter] >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function >>> '_ecore_evas_win32_cursor_set': >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c:814:42: warning: unused >>> parameter 'ee' [-Wunused-parameter] >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c:814:59: warning: unused >>> parameter 'obj' [-Wunused-parameter] >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c:814:68: warning: unused >>> parameter 'layer' [-Wunused-parameter] >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c:814:79: warning: unused >>> parameter 'hot_x' [-Wunused-parameter] >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c:814:90: warning: unused >>> parameter 'hot_y' [-Wunused-parameter] >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function >>> '_ecore_evas_win32_alpha_set': >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c:979:34: warning: unused >>> variable 'wdata' [-Wunused-variable] >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function >>> '_ecore_evas_win32_screen_dpi_get': >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c:1056:52: warning: >>> unused parameter 'ee' [-Wunused-parameter] >> >> please also fix these with EINA_UNUSED after the unused parameter name. >> >> >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function >>> '_ecore_evas_win32_new_internal': >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c:1324:38: warning: >>> declaration of '_ecore_evas_engine_init' shadows a global declaration >>> [-Wshadow] >>> ../src/lib/ecore_evas/ecore_evas_private.h:403:6: warning: shadowed >>> declaration is here [-Wshadow] >> >> this is a regular programming mistake. Just fix the declaration of >> _ecore_evas_engine_init :-) >> >> >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c:1354:4: error: 'iface' >>> undeclared (first use in this function) >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c:1354:4: note: each >>> undeclared identifier is reported only once for each function it appears in >> >> also another programming mistake. Please look at other ecore_evas >> engines and see their handling of "iface". It's nothing related to >> platform dependent stuff, just need to declare the variable with the >> proper ecore evas engine type. >> >> >>> modules/ecore_evas/engines/win32/ecore_e
Re: [E-devel] efl merge and win32
On Mon, Jan 14, 2013 at 12:03 PM, Cedric BAIL wrote: > On Mon, Jan 14, 2013 at 7:51 PM, Gustavo Sverzut Barbieri > wrote: >> On Mon, Jan 14, 2013 at 4:53 AM, Nicolas Aguirre >> wrote: >>> 2013/1/11 Gustavo Sverzut Barbieri On Fri, Jan 11, 2013 at 4:43 PM, Nicolas Aguirre wrote: modules/ecore_evas/engines/win32/modules_ecore_evas_engines_win32_module_la-ecore_evas_win32.lo > In file included from > modules/ecore_evas/engines/win32/ecore_evas_win32.c:19:0: error: > unterminated #ifdef > make[4]: *** > [modules/ecore_evas/engines/win32/modules_ecore_evas_engines_win32_module_la-ecore_evas_win32.lo] > Error 1 Flavio split ecore-evas engines out of ecore_evas itself, but seems he couldn't test with win32. It should be a matter of basing the fixes on other modules. Very likely these are just C errors that once fixed will work. > Anyway I'm away this week end, i will look into it next week. It's better if you can engage for couple of days into that. It will require lots of work and compilation rounds, not just the code changed, but the build system as well. Maybe some modules will have to be disabled, etc. >>> after ifdef correction (patch attached) i get a new kind of error, and i >>> fear it's related with all include you removed. >>> >>> Making all in src >>> make all-recursive >>> CC >>> modules/ecore_evas/engines/win32/modules_ecore_evas_engines_win32_module_la-ecore_evas_win32.lo >>> In file included from >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c:12:0: >>> ../src/lib/ecore_win32/Ecore_Win32.h:14:4: warning: #warning "You are using >>> a work in progress API. This API is not stable" [-Wcpp] >>> ../src/lib/ecore_win32/Ecore_Win32.h:15:4: warning: #warning "and is >>> subject to change. You use this at your own risk." [-Wcpp] >> >> ugh, this is annoying... what about if you patch Ecore_Win32.h to do >> like other libraries: >> >> #ifndef _ECORE_WIN32_API_IS_UNSTABLE_AND_I_KNOW_IT >> #warning "..."" >> #endif >> >> then define that for every user file in EFL. It does pollute too much >> and maybe that caused the confusion. See below. >> >> >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function >>> '_ecore_evas_win32_event_window_damage': >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c:258:3: warning: >>> #warning [ECORE] [WIN32] No Region code [-Wcpp] >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function >>> '_ecore_evas_win32_rotation_set': >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c:630:66: warning: unused >>> parameter 'resize' [-Wunused-parameter] >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function >>> '_ecore_evas_win32_cursor_set': >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c:814:42: warning: unused >>> parameter 'ee' [-Wunused-parameter] >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c:814:59: warning: unused >>> parameter 'obj' [-Wunused-parameter] >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c:814:68: warning: unused >>> parameter 'layer' [-Wunused-parameter] >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c:814:79: warning: unused >>> parameter 'hot_x' [-Wunused-parameter] >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c:814:90: warning: unused >>> parameter 'hot_y' [-Wunused-parameter] >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function >>> '_ecore_evas_win32_alpha_set': >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c:979:34: warning: unused >>> variable 'wdata' [-Wunused-variable] >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function >>> '_ecore_evas_win32_screen_dpi_get': >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c:1056:52: warning: >>> unused parameter 'ee' [-Wunused-parameter] >> >> please also fix these with EINA_UNUSED after the unused parameter name. >> >> >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function >>> '_ecore_evas_win32_new_internal': >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c:1324:38: warning: >>> declaration of '_ecore_evas_engine_init' shadows a global declaration >>> [-Wshadow] >>> ../src/lib/ecore_evas/ecore_evas_private.h:403:6: warning: shadowed >>> declaration is here [-Wshadow] >> >> this is a regular programming mistake. Just fix the declaration of >> _ecore_evas_engine_init :-) >> >> >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c:1354:4: error: 'iface' >>> undeclared (first use in this function) >>> modules/ecore_evas/engines/win32/ecore_evas_win32.c:1354:4: note: each >>> undeclared identifier is reported only once for each function it appears in >> >> also another programming mistake. Please look at other ecore_evas >> engines and see their handling of "iface". It's nothing related to >> platform dependent stuff, just need to declare the variable with the >> proper ecore evas engine type. >> >> >>> modules/ecore_evas/engines/win32/ecore_e
Re: [E-devel] efl merge and win32
On Mon, Jan 14, 2013 at 7:51 PM, Gustavo Sverzut Barbieri wrote: > On Mon, Jan 14, 2013 at 4:53 AM, Nicolas Aguirre > wrote: >> 2013/1/11 Gustavo Sverzut Barbieri >>> On Fri, Jan 11, 2013 at 4:43 PM, Nicolas Aguirre >>> wrote: >>> modules/ecore_evas/engines/win32/modules_ecore_evas_engines_win32_module_la-ecore_evas_win32.lo >>> > In file included from >>> > modules/ecore_evas/engines/win32/ecore_evas_win32.c:19:0: error: >>> > unterminated #ifdef >>> > make[4]: *** >>> > >>> [modules/ecore_evas/engines/win32/modules_ecore_evas_engines_win32_module_la-ecore_evas_win32.lo] >>> > Error 1 >>> >>> Flavio split ecore-evas engines out of ecore_evas itself, but seems he >>> couldn't test with win32. It should be a matter of basing the fixes on >>> other modules. Very likely these are just C errors that once fixed >>> will work. >>> >>> >>> > Anyway I'm away this week end, i will look into it next week. >>> >>> It's better if you can engage for couple of days into that. It will >>> require lots of work and compilation rounds, not just the code >>> changed, but the build system as well. Maybe some modules will have to >>> be disabled, etc. >>> >> after ifdef correction (patch attached) i get a new kind of error, and i >> fear it's related with all include you removed. >> >> Making all in src >> make all-recursive >> CC >> modules/ecore_evas/engines/win32/modules_ecore_evas_engines_win32_module_la-ecore_evas_win32.lo >> In file included from >> modules/ecore_evas/engines/win32/ecore_evas_win32.c:12:0: >> ../src/lib/ecore_win32/Ecore_Win32.h:14:4: warning: #warning "You are using >> a work in progress API. This API is not stable" [-Wcpp] >> ../src/lib/ecore_win32/Ecore_Win32.h:15:4: warning: #warning "and is >> subject to change. You use this at your own risk." [-Wcpp] > > ugh, this is annoying... what about if you patch Ecore_Win32.h to do > like other libraries: > > #ifndef _ECORE_WIN32_API_IS_UNSTABLE_AND_I_KNOW_IT > #warning "..."" > #endif > > then define that for every user file in EFL. It does pollute too much > and maybe that caused the confusion. See below. > > >> modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function >> '_ecore_evas_win32_event_window_damage': >> modules/ecore_evas/engines/win32/ecore_evas_win32.c:258:3: warning: >> #warning [ECORE] [WIN32] No Region code [-Wcpp] >> modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function >> '_ecore_evas_win32_rotation_set': >> modules/ecore_evas/engines/win32/ecore_evas_win32.c:630:66: warning: unused >> parameter 'resize' [-Wunused-parameter] >> modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function >> '_ecore_evas_win32_cursor_set': >> modules/ecore_evas/engines/win32/ecore_evas_win32.c:814:42: warning: unused >> parameter 'ee' [-Wunused-parameter] >> modules/ecore_evas/engines/win32/ecore_evas_win32.c:814:59: warning: unused >> parameter 'obj' [-Wunused-parameter] >> modules/ecore_evas/engines/win32/ecore_evas_win32.c:814:68: warning: unused >> parameter 'layer' [-Wunused-parameter] >> modules/ecore_evas/engines/win32/ecore_evas_win32.c:814:79: warning: unused >> parameter 'hot_x' [-Wunused-parameter] >> modules/ecore_evas/engines/win32/ecore_evas_win32.c:814:90: warning: unused >> parameter 'hot_y' [-Wunused-parameter] >> modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function >> '_ecore_evas_win32_alpha_set': >> modules/ecore_evas/engines/win32/ecore_evas_win32.c:979:34: warning: unused >> variable 'wdata' [-Wunused-variable] >> modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function >> '_ecore_evas_win32_screen_dpi_get': >> modules/ecore_evas/engines/win32/ecore_evas_win32.c:1056:52: warning: >> unused parameter 'ee' [-Wunused-parameter] > > please also fix these with EINA_UNUSED after the unused parameter name. > > >> modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function >> '_ecore_evas_win32_new_internal': >> modules/ecore_evas/engines/win32/ecore_evas_win32.c:1324:38: warning: >> declaration of '_ecore_evas_engine_init' shadows a global declaration >> [-Wshadow] >> ../src/lib/ecore_evas/ecore_evas_private.h:403:6: warning: shadowed >> declaration is here [-Wshadow] > > this is a regular programming mistake. Just fix the declaration of > _ecore_evas_engine_init :-) > > >> modules/ecore_evas/engines/win32/ecore_evas_win32.c:1354:4: error: 'iface' >> undeclared (first use in this function) >> modules/ecore_evas/engines/win32/ecore_evas_win32.c:1354:4: note: each >> undeclared identifier is reported only once for each function it appears in > > also another programming mistake. Please look at other ecore_evas > engines and see their handling of "iface". It's nothing related to > platform dependent stuff, just need to declare the variable with the > proper ecore evas engine type. > > >> modules/ecore_evas/engines/win32/ecore_evas_win32.c: At top level: >> modules/ecore_evas/engines/win32/ecore_evas_win32.c:1412:1: warning: >> 'ecore_evas_software_gdi_new' already declared with dllexport at
Re: [E-devel] efl merge and win32
On Mon, Jan 14, 2013 at 4:53 AM, Nicolas Aguirre wrote: > 2013/1/11 Gustavo Sverzut Barbieri > >> On Fri, Jan 11, 2013 at 4:43 PM, Nicolas Aguirre >> wrote: >> >> > >> modules/ecore_evas/engines/win32/modules_ecore_evas_engines_win32_module_la-ecore_evas_win32.lo >> > In file included from >> > modules/ecore_evas/engines/win32/ecore_evas_win32.c:19:0: error: >> > unterminated #ifdef >> > make[4]: *** >> > >> [modules/ecore_evas/engines/win32/modules_ecore_evas_engines_win32_module_la-ecore_evas_win32.lo] >> > Error 1 >> >> Flavio split ecore-evas engines out of ecore_evas itself, but seems he >> couldn't test with win32. It should be a matter of basing the fixes on >> other modules. Very likely these are just C errors that once fixed >> will work. >> >> >> > Anyway I'm away this week end, i will look into it next week. >> >> It's better if you can engage for couple of days into that. It will >> require lots of work and compilation rounds, not just the code >> changed, but the build system as well. Maybe some modules will have to >> be disabled, etc. >> >> >> > after ifdef correction (patch attached) i get a new kind of error, and i > fear it's related with all include you removed. > > Making all in src > make all-recursive > CC > modules/ecore_evas/engines/win32/modules_ecore_evas_engines_win32_module_la-ecore_evas_win32.lo > In file included from > modules/ecore_evas/engines/win32/ecore_evas_win32.c:12:0: > ../src/lib/ecore_win32/Ecore_Win32.h:14:4: warning: #warning "You are using > a work in progress API. This API is not stable" [-Wcpp] > ../src/lib/ecore_win32/Ecore_Win32.h:15:4: warning: #warning "and is > subject to change. You use this at your own risk." [-Wcpp] ugh, this is annoying... what about if you patch Ecore_Win32.h to do like other libraries: #ifndef _ECORE_WIN32_API_IS_UNSTABLE_AND_I_KNOW_IT #warning "..."" #endif then define that for every user file in EFL. It does pollute too much and maybe that caused the confusion. See below. > modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function > '_ecore_evas_win32_event_window_damage': > modules/ecore_evas/engines/win32/ecore_evas_win32.c:258:3: warning: > #warning [ECORE] [WIN32] No Region code [-Wcpp] > modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function > '_ecore_evas_win32_rotation_set': > modules/ecore_evas/engines/win32/ecore_evas_win32.c:630:66: warning: unused > parameter 'resize' [-Wunused-parameter] > modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function > '_ecore_evas_win32_cursor_set': > modules/ecore_evas/engines/win32/ecore_evas_win32.c:814:42: warning: unused > parameter 'ee' [-Wunused-parameter] > modules/ecore_evas/engines/win32/ecore_evas_win32.c:814:59: warning: unused > parameter 'obj' [-Wunused-parameter] > modules/ecore_evas/engines/win32/ecore_evas_win32.c:814:68: warning: unused > parameter 'layer' [-Wunused-parameter] > modules/ecore_evas/engines/win32/ecore_evas_win32.c:814:79: warning: unused > parameter 'hot_x' [-Wunused-parameter] > modules/ecore_evas/engines/win32/ecore_evas_win32.c:814:90: warning: unused > parameter 'hot_y' [-Wunused-parameter] > modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function > '_ecore_evas_win32_alpha_set': > modules/ecore_evas/engines/win32/ecore_evas_win32.c:979:34: warning: unused > variable 'wdata' [-Wunused-variable] > modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function > '_ecore_evas_win32_screen_dpi_get': > modules/ecore_evas/engines/win32/ecore_evas_win32.c:1056:52: warning: > unused parameter 'ee' [-Wunused-parameter] please also fix these with EINA_UNUSED after the unused parameter name. > modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function > '_ecore_evas_win32_new_internal': > modules/ecore_evas/engines/win32/ecore_evas_win32.c:1324:38: warning: > declaration of '_ecore_evas_engine_init' shadows a global declaration > [-Wshadow] > ../src/lib/ecore_evas/ecore_evas_private.h:403:6: warning: shadowed > declaration is here [-Wshadow] this is a regular programming mistake. Just fix the declaration of _ecore_evas_engine_init :-) > modules/ecore_evas/engines/win32/ecore_evas_win32.c:1354:4: error: 'iface' > undeclared (first use in this function) > modules/ecore_evas/engines/win32/ecore_evas_win32.c:1354:4: note: each > undeclared identifier is reported only once for each function it appears in also another programming mistake. Please look at other ecore_evas engines and see their handling of "iface". It's nothing related to platform dependent stuff, just need to declare the variable with the proper ecore evas engine type. > modules/ecore_evas/engines/win32/ecore_evas_win32.c: At top level: > modules/ecore_evas/engines/win32/ecore_evas_win32.c:1412:1: warning: > 'ecore_evas_software_gdi_new' already declared with dllexport attribute: > dllimport ignored [-Wattributes] > modules/ecore_evas/engines/win32/ecore_evas_win32.c:1443:1: warning: > 'ecore_evas_software_ddraw_new' already declared with dllex
Re: [E-devel] efl merge and win32
2013/1/11 Gustavo Sverzut Barbieri > On Fri, Jan 11, 2013 at 4:43 PM, Nicolas Aguirre > wrote: > > > > modules/ecore_evas/engines/win32/modules_ecore_evas_engines_win32_module_la-ecore_evas_win32.lo > > In file included from > > modules/ecore_evas/engines/win32/ecore_evas_win32.c:19:0: error: > > unterminated #ifdef > > make[4]: *** > > > [modules/ecore_evas/engines/win32/modules_ecore_evas_engines_win32_module_la-ecore_evas_win32.lo] > > Error 1 > > Flavio split ecore-evas engines out of ecore_evas itself, but seems he > couldn't test with win32. It should be a matter of basing the fixes on > other modules. Very likely these are just C errors that once fixed > will work. > > > > Anyway I'm away this week end, i will look into it next week. > > It's better if you can engage for couple of days into that. It will > require lots of work and compilation rounds, not just the code > changed, but the build system as well. Maybe some modules will have to > be disabled, etc. > > > after ifdef correction (patch attached) i get a new kind of error, and i fear it's related with all include you removed. Making all in src make all-recursive CC modules/ecore_evas/engines/win32/modules_ecore_evas_engines_win32_module_la-ecore_evas_win32.lo In file included from modules/ecore_evas/engines/win32/ecore_evas_win32.c:12:0: ../src/lib/ecore_win32/Ecore_Win32.h:14:4: warning: #warning "You are using a work in progress API. This API is not stable" [-Wcpp] ../src/lib/ecore_win32/Ecore_Win32.h:15:4: warning: #warning "and is subject to change. You use this at your own risk." [-Wcpp] modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function '_ecore_evas_win32_event_window_damage': modules/ecore_evas/engines/win32/ecore_evas_win32.c:258:3: warning: #warning [ECORE] [WIN32] No Region code [-Wcpp] modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function '_ecore_evas_win32_rotation_set': modules/ecore_evas/engines/win32/ecore_evas_win32.c:630:66: warning: unused parameter 'resize' [-Wunused-parameter] modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function '_ecore_evas_win32_cursor_set': modules/ecore_evas/engines/win32/ecore_evas_win32.c:814:42: warning: unused parameter 'ee' [-Wunused-parameter] modules/ecore_evas/engines/win32/ecore_evas_win32.c:814:59: warning: unused parameter 'obj' [-Wunused-parameter] modules/ecore_evas/engines/win32/ecore_evas_win32.c:814:68: warning: unused parameter 'layer' [-Wunused-parameter] modules/ecore_evas/engines/win32/ecore_evas_win32.c:814:79: warning: unused parameter 'hot_x' [-Wunused-parameter] modules/ecore_evas/engines/win32/ecore_evas_win32.c:814:90: warning: unused parameter 'hot_y' [-Wunused-parameter] modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function '_ecore_evas_win32_alpha_set': modules/ecore_evas/engines/win32/ecore_evas_win32.c:979:34: warning: unused variable 'wdata' [-Wunused-variable] modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function '_ecore_evas_win32_screen_dpi_get': modules/ecore_evas/engines/win32/ecore_evas_win32.c:1056:52: warning: unused parameter 'ee' [-Wunused-parameter] modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function '_ecore_evas_win32_new_internal': modules/ecore_evas/engines/win32/ecore_evas_win32.c:1324:38: warning: declaration of '_ecore_evas_engine_init' shadows a global declaration [-Wshadow] ../src/lib/ecore_evas/ecore_evas_private.h:403:6: warning: shadowed declaration is here [-Wshadow] modules/ecore_evas/engines/win32/ecore_evas_win32.c:1354:4: error: 'iface' undeclared (first use in this function) modules/ecore_evas/engines/win32/ecore_evas_win32.c:1354:4: note: each undeclared identifier is reported only once for each function it appears in modules/ecore_evas/engines/win32/ecore_evas_win32.c: At top level: modules/ecore_evas/engines/win32/ecore_evas_win32.c:1412:1: warning: 'ecore_evas_software_gdi_new' already declared with dllexport attribute: dllimport ignored [-Wattributes] modules/ecore_evas/engines/win32/ecore_evas_win32.c:1443:1: warning: 'ecore_evas_software_ddraw_new' already declared with dllexport attribute: dllimport ignored [-Wattributes] modules/ecore_evas/engines/win32/ecore_evas_win32.c:1473:1: warning: 'ecore_evas_software_16_ddraw_new' already declared with dllexport attribute: dllimport ignored [-Wattributes] modules/ecore_evas/engines/win32/ecore_evas_win32.c:1502:1: warning: 'ecore_evas_direct3d_new' already declared with dllexport attribute: dllimport ignored [-Wattributes] modules/ecore_evas/engines/win32/ecore_evas_win32.c:1534:1: warning: 'ecore_evas_gl_glew_new' already declared with dllexport attribute: dllimport ignored [-Wattributes] modules/ecore_evas/engines/win32/ecore_evas_win32.c: In function '_ecore_evas_win32_interface_new': modules/ecore_evas/engines/win32/ecore_evas_win32.c:1559:23: error: 'interface_win32_name' undeclared (first use in this function) modules/ecore_evas/engines/win32/ecore_evas_win32.c:1560:26: error: 'interface_win32_version' undec
Re: [E-devel] efl merge and win32
On Fri, Jan 11, 2013, Carsten Haitzler wrote: > On Fri, 11 Jan 2013 13:59:48 +1000 David Seikel said: > > > On Fri, 11 Jan 2013 11:51:04 +0900 Cedric BAIL > > wrote: > > > > > On Fri, Jan 11, 2013 at 11:46 AM, Carsten Haitzler > > > wrote: > > > > On Fri, 11 Jan 2013 09:46:42 +0900 Cedric BAIL > > > > said: > > > >> On Fri, Jan 11, 2013 at 9:26 AM, Carsten Haitzler > > > >> wrote: > > > >> > On Fri, 11 Jan 2013 09:08:20 +0900 Cedric BAIL > > > >> > said: > > > >> >> On Fri, Jan 11, 2013 at 7:51 AM, Nicolas Aguirre > > > >> >> 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:
Re: [E-devel] efl merge and win32
On Fri, Jan 11, 2013 at 4:43 PM, Nicolas Aguirre wrote: > modules/ecore_evas/engines/win32/modules_ecore_evas_engines_win32_module_la-ecore_evas_win32.lo > In file included from > modules/ecore_evas/engines/win32/ecore_evas_win32.c:19:0: error: > unterminated #ifdef > make[4]: *** > [modules/ecore_evas/engines/win32/modules_ecore_evas_engines_win32_module_la-ecore_evas_win32.lo] > Error 1 Flavio split ecore-evas engines out of ecore_evas itself, but seems he couldn't test with win32. It should be a matter of basing the fixes on other modules. Very likely these are just C errors that once fixed will work. > Anyway I'm away this week end, i will look into it next week. It's better if you can engage for couple of days into that. It will require lots of work and compilation rounds, not just the code changed, but the build system as well. Maybe some modules will have to be disabled, etc. -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: barbi...@gmail.com Skype: gsbarbieri Mobile: +55 (19) 9225-2202 -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of 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_122812 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl merge and win32
2013/1/11 Gustavo Sverzut Barbieri
> On Fri, Jan 11, 2013 at 2:55 PM, Nicolas Aguirre
> wrote:
> >
> > 2013/1/11 Gustavo Sverzut Barbieri
> >
> > > On Friday, January 11, 2013, Nicolas Aguirre wrote:
> > >
> > > > 2013/1/11 Gustavo Sverzut Barbieri
> > > > >
> > > >
> > > > > On Thu, Jan 10, 2013 at 8:51 PM, Nicolas Aguirre
> > > > > >wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > 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.
> > > > > >
> > > > >
> > > > > Thanks, in SVN.
> > > > >
> > > > >
> > > > > 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 ?
> > > > > >
> > > > >
> > > > > Likely due the cross compilation. Right now it reads:
> > > > >
> > > > > EFL_LIB_START_OPTIONAL([Eeze], [test "${have_linux}" = "yes"])
> > > > >
> > > > > Based on:
> > > > > case "$host_os" in
> > > > >mingw32ce*)
> > > > > have_wince="yes"
> > > > > have_windows="yes"
> > > > >;;
> > > > >mingw*|cygwin*)
> > > > > # TODO: check cygwin* here
> > > > > have_win32="yes"
> > > > > have_windows="yes"
> > > > >;;
> > > > >darwin*)
> > > > > have_darwin="yes"
> > > > >;;
> > > > >linux*)
> > > > > have_linux="yes"
> > > > >;;
> > > > > esac
> > > > >
> > > > > I thought that even being "host_os", the mingw* would redefine
> it...
> > > but
> > > > I
> > > > > was wrong. Do you have the information about that? If you're
> getting
> > > > linux
> > > > > = yes, then all your modules cross compiled for Windows are named
> > > linux?!
> > > > > :-/ Later on we have:
> > > > > MODULE_ARCH="$host_os-$host_cpu-v_maj.v_min.v_mic"
> > > > > MODULE_EXT=".dll"
> > > > >
> > > > > that was the reasoning of my thought.
> > > > >
> > > > >
> > > > Based on the 1.7.3 branch when i build evas, the gdi engine is named
> > > > : lib/evas/modules/engines/software_gdi/mingw32-i686-1.7.3/module.dll
> > > > host_os =mingw32
> > > > host_cpu = i686
> > >
> > >
> > > As I expected. But then what do you get in trunk? See config.log
> > >
> > >
> > here my config.log
> > http://pastebin.com/TNgY1dGS
>
>
> weird, the only error I found is the AM_CONDITIONAL... now fixed with
> r82649. Check it again.
>
> In that eeze is disabled, as expected. Did you change the
> configure.ac? I see your command line uses --disable-eeze which does
> not exist. What is not working?
>
>configure:42640: Skipping Eeze checks (disabled)
>configure:43264: Skipping EPhysics checks (disabled)
>
>
> Also, as a hint your command line can be simplified, if you
> --disable-audio it will disable pulseaudio. Just the Gstreamer needs
> to stay as it's used by ecore example, emotion and ecore_audio.
>
>
with r82649 configure passed, here the resume :
efl 1.7.99.82655
Configuration Options Summary:
OS...: mingw32
Windows version..: Windows XP
Build Profile: dev
CPU Extensions...: i686 (+mmx +sse3)
System Features..: -inotify +notify_win32 -atfile -ipv6
Threads Type.: Windows
spinlocks..: no
barrier: no
affinity...: yes
Cryptographic System.: gnutls
Evas:
Engines:
Software X11...: none
OpenGL X11.: none (opengl=none)
Software GDI...: yes
Software DirectDraw: yes
OpenGL SDL.: no (opengl=none)
OpenGL Cocoa...: no
Software Framebuffer...: no
PSL1GHT: no
Wayland Shm: no
Wayland Egl: no
Image Loaders:
JPEG region decode..: no
WEBP: no
GIF.: yes
TIFF: yes
SVG.: no
Font Searching Systems:
Fontconfig..: yes
Font Rendering Helpers:
Fribidi.: yes
Harfbuzz: no
Features:
Cache Server 2..: no
Optional pixman rendering path:
Pixman..: no
Pixman Fonts: no
Pixman Rects: no
Pixman Lines: no
Pixman Polygons.: no
Re: [E-devel] efl merge and win32
On Fri, Jan 11, 2013 at 2:55 PM, Nicolas Aguirre
wrote:
>
> 2013/1/11 Gustavo Sverzut Barbieri
>
> > On Friday, January 11, 2013, Nicolas Aguirre wrote:
> >
> > > 2013/1/11 Gustavo Sverzut Barbieri
> > > >
> > >
> > > > On Thu, Jan 10, 2013 at 8:51 PM, Nicolas Aguirre
> > > > >wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > 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.
> > > > >
> > > >
> > > > Thanks, in SVN.
> > > >
> > > >
> > > > 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 ?
> > > > >
> > > >
> > > > Likely due the cross compilation. Right now it reads:
> > > >
> > > > EFL_LIB_START_OPTIONAL([Eeze], [test "${have_linux}" = "yes"])
> > > >
> > > > Based on:
> > > > case "$host_os" in
> > > >mingw32ce*)
> > > > have_wince="yes"
> > > > have_windows="yes"
> > > >;;
> > > >mingw*|cygwin*)
> > > > # TODO: check cygwin* here
> > > > have_win32="yes"
> > > > have_windows="yes"
> > > >;;
> > > >darwin*)
> > > > have_darwin="yes"
> > > >;;
> > > >linux*)
> > > > have_linux="yes"
> > > >;;
> > > > esac
> > > >
> > > > I thought that even being "host_os", the mingw* would redefine it...
> > but
> > > I
> > > > was wrong. Do you have the information about that? If you're getting
> > > linux
> > > > = yes, then all your modules cross compiled for Windows are named
> > linux?!
> > > > :-/ Later on we have:
> > > > MODULE_ARCH="$host_os-$host_cpu-v_maj.v_min.v_mic"
> > > > MODULE_EXT=".dll"
> > > >
> > > > that was the reasoning of my thought.
> > > >
> > > >
> > > Based on the 1.7.3 branch when i build evas, the gdi engine is named
> > > : lib/evas/modules/engines/software_gdi/mingw32-i686-1.7.3/module.dll
> > > host_os =mingw32
> > > host_cpu = i686
> >
> >
> > As I expected. But then what do you get in trunk? See config.log
> >
> >
> here my config.log
> http://pastebin.com/TNgY1dGS
weird, the only error I found is the AM_CONDITIONAL... now fixed with
r82649. Check it again.
In that eeze is disabled, as expected. Did you change the
configure.ac? I see your command line uses --disable-eeze which does
not exist. What is not working?
configure:42640: Skipping Eeze checks (disabled)
configure:43264: Skipping EPhysics checks (disabled)
Also, as a hint your command line can be simplified, if you
--disable-audio it will disable pulseaudio. Just the Gstreamer needs
to stay as it's used by ecore example, emotion and ecore_audio.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of 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_122812
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl merge and win32
2013/1/11 Gustavo Sverzut Barbieri
> On Friday, January 11, 2013, Nicolas Aguirre wrote:
>
> > 2013/1/11 Gustavo Sverzut Barbieri
> > >
> >
> > > On Thu, Jan 10, 2013 at 8:51 PM, Nicolas Aguirre
> > > >wrote:
> > >
> > > > Hi,
> > > >
> > > > 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.
> > > >
> > >
> > > Thanks, in SVN.
> > >
> > >
> > > 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 ?
> > > >
> > >
> > > Likely due the cross compilation. Right now it reads:
> > >
> > > EFL_LIB_START_OPTIONAL([Eeze], [test "${have_linux}" = "yes"])
> > >
> > > Based on:
> > > case "$host_os" in
> > >mingw32ce*)
> > > have_wince="yes"
> > > have_windows="yes"
> > >;;
> > >mingw*|cygwin*)
> > > # TODO: check cygwin* here
> > > have_win32="yes"
> > > have_windows="yes"
> > >;;
> > >darwin*)
> > > have_darwin="yes"
> > >;;
> > >linux*)
> > > have_linux="yes"
> > >;;
> > > esac
> > >
> > > I thought that even being "host_os", the mingw* would redefine it...
> but
> > I
> > > was wrong. Do you have the information about that? If you're getting
> > linux
> > > = yes, then all your modules cross compiled for Windows are named
> linux?!
> > > :-/ Later on we have:
> > > MODULE_ARCH="$host_os-$host_cpu-v_maj.v_min.v_mic"
> > > MODULE_EXT=".dll"
> > >
> > > that was the reasoning of my thought.
> > >
> > >
> > Based on the 1.7.3 branch when i build evas, the gdi engine is named
> > : lib/evas/modules/engines/software_gdi/mingw32-i686-1.7.3/module.dll
> > host_os =mingw32
> > host_cpu = i686
>
>
> As I expected. But then what do you get in trunk? See config.log
>
>
here my config.log
http://pastebin.com/TNgY1dGS
>
> >
> >
> > >
> > > There will be no --disable-eeze.
> > >
> >
> > It will be perfect !
> >
> > --
> > Nicolas Aguirre
> > Mail: aguirre.nico...@gmail.com
> > Web: http://enna.geexbox.org
> > Blog: http://dev.enlightenment.fr/~captainigloo/
> >
> >
> --
> > Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
> > much more. Get web development skills now with LearnDevNow -
> > 350+ hours of 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_122812
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
>
>
> --
> Gustavo Sverzut Barbieri
> http://profusion.mobi embedded systems
> --
> MSN: barbi...@gmail.com
> Skype: gsbarbieri
> Mobile: +55 (19) 9225-2202
>
> --
> Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
> much more. Get web development skills now with LearnDevNow -
> 350+ hours of 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_122812
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Nicolas Aguirre
Mail: aguirre.nico...@gmail.com
Web: http://enna.geexbox.org
Blog: http://dev.enlightenment.fr/~captainigloo/
--
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of 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_122812
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl merge and win32
On Friday, January 11, 2013, Nicolas Aguirre wrote:
> 2013/1/11 Gustavo Sverzut Barbieri
> >
>
> > On Thu, Jan 10, 2013 at 8:51 PM, Nicolas Aguirre
> > >wrote:
> >
> > > Hi,
> > >
> > > 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.
> > >
> >
> > Thanks, in SVN.
> >
> >
> > 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 ?
> > >
> >
> > Likely due the cross compilation. Right now it reads:
> >
> > EFL_LIB_START_OPTIONAL([Eeze], [test "${have_linux}" = "yes"])
> >
> > Based on:
> > case "$host_os" in
> >mingw32ce*)
> > have_wince="yes"
> > have_windows="yes"
> >;;
> >mingw*|cygwin*)
> > # TODO: check cygwin* here
> > have_win32="yes"
> > have_windows="yes"
> >;;
> >darwin*)
> > have_darwin="yes"
> >;;
> >linux*)
> > have_linux="yes"
> >;;
> > esac
> >
> > I thought that even being "host_os", the mingw* would redefine it... but
> I
> > was wrong. Do you have the information about that? If you're getting
> linux
> > = yes, then all your modules cross compiled for Windows are named linux?!
> > :-/ Later on we have:
> > MODULE_ARCH="$host_os-$host_cpu-v_maj.v_min.v_mic"
> > MODULE_EXT=".dll"
> >
> > that was the reasoning of my thought.
> >
> >
> Based on the 1.7.3 branch when i build evas, the gdi engine is named
> : lib/evas/modules/engines/software_gdi/mingw32-i686-1.7.3/module.dll
> host_os =mingw32
> host_cpu = i686
As I expected. But then what do you get in trunk? See config.log
>
>
> >
> > There will be no --disable-eeze.
> >
>
> It will be perfect !
>
> --
> Nicolas Aguirre
> Mail: aguirre.nico...@gmail.com
> Web: http://enna.geexbox.org
> Blog: http://dev.enlightenment.fr/~captainigloo/
>
> --
> Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
> much more. Get web development skills now with LearnDevNow -
> 350+ hours of 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_122812
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of 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_122812
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl merge and win32
2013/1/11 Gustavo Sverzut Barbieri
> On Thu, Jan 10, 2013 at 8:51 PM, Nicolas Aguirre
> wrote:
>
> > Hi,
> >
> > 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.
> >
>
> Thanks, in SVN.
>
>
> 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 ?
> >
>
> Likely due the cross compilation. Right now it reads:
>
> EFL_LIB_START_OPTIONAL([Eeze], [test "${have_linux}" = "yes"])
>
> Based on:
> case "$host_os" in
>mingw32ce*)
> have_wince="yes"
> have_windows="yes"
>;;
>mingw*|cygwin*)
> # TODO: check cygwin* here
> have_win32="yes"
> have_windows="yes"
>;;
>darwin*)
> have_darwin="yes"
>;;
>linux*)
> have_linux="yes"
>;;
> esac
>
> I thought that even being "host_os", the mingw* would redefine it... but I
> was wrong. Do you have the information about that? If you're getting linux
> = yes, then all your modules cross compiled for Windows are named linux?!
> :-/ Later on we have:
> MODULE_ARCH="$host_os-$host_cpu-v_maj.v_min.v_mic"
> MODULE_EXT=".dll"
>
> that was the reasoning of my thought.
>
>
Based on the 1.7.3 branch when i build evas, the gdi engine is named
: lib/evas/modules/engines/software_gdi/mingw32-i686-1.7.3/module.dll
host_os =mingw32
host_cpu = i686
>
> There will be no --disable-eeze.
>
It will be perfect !
--
Nicolas Aguirre
Mail: aguirre.nico...@gmail.com
Web: http://enna.geexbox.org
Blog: http://dev.enlightenment.fr/~captainigloo/
--
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of 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_122812
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl merge and win32
2013/1/11 Carsten Haitzler > On Fri, 11 Jan 2013 09:08:20 +0900 Cedric BAIL said: > > > Yop, > > > > On Fri, Jan 11, 2013 at 7:51 AM, Nicolas Aguirre > > 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... > I don't think so, cross compilation is better in any case, it's faster, it's easy, and it's already present in almost all recent distributions. It's also easy to build for 32 and 64 architecture with no extra cost. About the windows version i don't know exatcly but i think you're right with xp you should target all later versions. if you want to set up your machine for a build, Vincent did a build of all dependencies http://dev.enlightenment.fr/~doursse/efl_dep.zip it's for 32bits only architecture. Then you need to install mingw-w64 and gcc-mingw-w64-i686 Once unzip you only need to export few env vars : base=`pwd` export TARGET=i686-w64-mingw32 export MINGW_PREFIX="$base/package/" export CPPFLAGS="-I$MINGW_PREFIX/include -I$MINGW_PREFIX/include/evil-1 -I$MINGW_PREFIX/include/freetype2" export CXXFLAGS="$CFLAGS" export LDFLAGS="$LDFLAGS -L$MINGW_PREFIX/lib" export PATH="$HOME/local/opt/mingw-w64-x86_32/bin:$MINGW_PREFIX/bin:$PATH" export LD_LIBRARY_PATH="$MINGW_PREFIX/lib" export PKG_CONFIG_PATH="$MINGW_PREFIX/lib/pkgconfig" export PKG_CONFIG_LIBDIR="$MINGW_PREFIX/lib/pkgconfig" and then you can compile as usual efl : ./autogen.sh --prefix=$MINGW_PREFIX --host=$TARGET --disable-static That's all, it's really easy, and we don't need a real windows machine for that. Of course if you want automated it's better, but i don't think we have man power for this. regards, -- Nicolas Aguirre Mail: aguirre.nico...@gmail.com Web: http://enna.geexbox.org Blog: http://dev.enlightenment.fr/~captainigloo/ -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of 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_122812 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl merge and win32
On Fri, 11 Jan 2013 14:14:38 +0900 Carsten Haitzler (The Rasterman) wrote: > On Fri, 11 Jan 2013 13:59:48 +1000 David Seikel > said: > > > On Fri, 11 Jan 2013 11:51:04 +0900 Cedric BAIL > > wrote: > > > > > On Fri, Jan 11, 2013 at 11:46 AM, Carsten Haitzler > > > wrote: > > > > On Fri, 11 Jan 2013 09:46:42 +0900 Cedric BAIL > > > > said: > > > >> On Fri, Jan 11, 2013 at 9:26 AM, Carsten Haitzler > > > >> wrote: > > > >> > On Fri, 11 Jan 2013 09:08:20 +0900 Cedric BAIL > > > >> > said: > > > >> >> On Fri, Jan 11, 2013 at 7:51 AM, Nicolas Aguirre > > > >> >> 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.). > > > BTW, I already have a qemu VM for Windows XP and 7 specifically for > > testing stuff with. I just can't bring myself to actually use it > > much. I hate Windows, but a lot of my users want it. More > > importantly, my girlfriend uses Windows. She who must be obeyed > > must be appeased. Coz not sure which is more painful, using > > Windows, or teaching her Linux. lol > > hahahaha! indeed. i just think we need to set up a shared vm that has > a mingw32 dev env installed with dropbear/sshd so u can ssh in and > "use it" to do builds at least. with rdesktop you could verify > rendering at least... and some behaviour. i guess with vnc too... :) Well, with qemu you don't have to use RDP. VNC to the host and look at the qemu window. B-) That's how I installed Win7 remotely an a clients VM host last year. KVM (qemu) and VNC. It can directly output to VNC. BTW, I'm part way through setting up a "fire up qemu and compile shit on Windows from a git repo" script. It's one Unix shell script that does everything from the script, no need for support scripts on the Windows guest. I figured out the thing is gonna be busy enough as it is compiling, ssh is just overkill, and a waste of precious CPU resources with all that doubled up encryption going on. Tripled ssh encryption if you are ssh'ed into the host in the first place and want to watch the compiling going on. Serial port is much saner. Security is not needed, the serial port only goes to the host, or in my case, the script on the host. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more a
Re: [E-devel] efl merge and win32
On Fri, 11 Jan 2013 13:59:48 +1000 David Seikel said: > On Fri, 11 Jan 2013 11:51:04 +0900 Cedric BAIL > wrote: > > > On Fri, Jan 11, 2013 at 11:46 AM, Carsten Haitzler > > wrote: > > > On Fri, 11 Jan 2013 09:46:42 +0900 Cedric BAIL > > > said: > > >> On Fri, Jan 11, 2013 at 9:26 AM, Carsten Haitzler > > >> wrote: > > >> > On Fri, 11 Jan 2013 09:08:20 +0900 Cedric BAIL > > >> > said: > > >> >> On Fri, Jan 11, 2013 at 7:51 AM, Nicolas Aguirre > > >> >> 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.). > BTW, I already have a qemu VM for Windows XP and 7 specifically for > testing stuff with. I just can't bring myself to actually use it > much. I hate Windows, but a lot of my users want it. More > importantly, my girlfriend uses Windows. She who must be obeyed must > be appeased. Coz not sure which is more painful, using Windows, or > teaching her Linux. lol hahahaha! indeed. i just think we need to set up a shared vm that has a mingw32 dev env installed with dropbear/sshd so u can ssh in and "use it" to do builds at least. with rdesktop you could verify rendering at least... and some behaviour. i guess with vnc too... :) > -- > A big old stinking pile of genius that no one wants > coz there are too many silver coated monkeys in the world. -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of 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_122812 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl merge and win32
On Fri, 11 Jan 2013 11:51:04 +0900 Cedric BAIL wrote: > On Fri, Jan 11, 2013 at 11:46 AM, Carsten Haitzler > wrote: > > On Fri, 11 Jan 2013 09:46:42 +0900 Cedric BAIL > > said: > >> On Fri, Jan 11, 2013 at 9:26 AM, Carsten Haitzler > >> wrote: > >> > On Fri, 11 Jan 2013 09:08:20 +0900 Cedric BAIL > >> > said: > >> >> On Fri, Jan 11, 2013 at 7:51 AM, Nicolas Aguirre > >> >> 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. BTW, I already have a qemu VM for Windows XP and 7 specifically for testing stuff with. I just can't bring myself to actually use it much. I hate Windows, but a lot of my users want it. More importantly, my girlfriend uses Windows. She who must be obeyed must be appeased. Coz not sure which is more painful, using Windows, or teaching her Linux. lol -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of 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_122812___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl merge and win32
On Thu, Jan 10, 2013 at 8:51 PM, Nicolas Aguirre
wrote:
> Hi,
>
> 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.
>
Thanks, in SVN.
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 ?
>
Likely due the cross compilation. Right now it reads:
EFL_LIB_START_OPTIONAL([Eeze], [test "${have_linux}" = "yes"])
Based on:
case "$host_os" in
mingw32ce*)
have_wince="yes"
have_windows="yes"
;;
mingw*|cygwin*)
# TODO: check cygwin* here
have_win32="yes"
have_windows="yes"
;;
darwin*)
have_darwin="yes"
;;
linux*)
have_linux="yes"
;;
esac
I thought that even being "host_os", the mingw* would redefine it... but I
was wrong. Do you have the information about that? If you're getting linux
= yes, then all your modules cross compiled for Windows are named linux?!
:-/ Later on we have:
MODULE_ARCH="$host_os-$host_cpu-v_maj.v_min.v_mic"
MODULE_EXT=".dll"
that was the reasoning of my thought.
There will be no --disable-eeze.
--
Gustavo Sverzut Barbieri
http://profusion.mobi embedded systems
--
MSN: barbi...@gmail.com
Skype: gsbarbieri
Mobile: +55 (19) 9225-2202
--
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of 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_122812
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl merge and win32
On Fri, Jan 11, 2013 at 11:46 AM, Carsten Haitzler wrote: > On Fri, 11 Jan 2013 09:46:42 +0900 Cedric BAIL said: >> On Fri, Jan 11, 2013 at 9:26 AM, Carsten Haitzler >> wrote: >> > On Fri, 11 Jan 2013 09:08:20 +0900 Cedric BAIL said: >> >> On Fri, Jan 11, 2013 at 7:51 AM, Nicolas Aguirre >> >> 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 :-) -- Cedric BAIL -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of 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_122812 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl merge and win32
On Fri, 11 Jan 2013 09:46:42 +0900 Cedric BAIL said: > On Fri, Jan 11, 2013 at 9:26 AM, Carsten Haitzler > wrote: > > On Fri, 11 Jan 2013 09:08:20 +0900 Cedric BAIL said: > >> On Fri, Jan 11, 2013 at 7:51 AM, Nicolas Aguirre > >> 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 -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of 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_122812 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl merge and win32
On Fri, Jan 11, 2013 at 9:26 AM, Carsten Haitzler wrote: > On Fri, 11 Jan 2013 09:08:20 +0900 Cedric BAIL said: >> On Fri, Jan 11, 2013 at 7:51 AM, Nicolas Aguirre >> 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... -- Cedric BAIL -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of 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_122812 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl merge and win32
On Fri, 11 Jan 2013 09:08:20 +0900 Cedric BAIL said: > Yop, > > On Fri, Jan 11, 2013 at 7:51 AM, Nicolas Aguirre > 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... -- - Codito, ergo sum - "I code, therefore I am" -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of 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_122812 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl merge and win32
Yop, On Fri, Jan 11, 2013 at 7:51 AM, Nicolas Aguirre 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. -- Cedric BAIL -- Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and much more. Get web development skills now with LearnDevNow - 350+ hours of 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_122812 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] efl merge and win32
Hi, 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 ? Regards, -- Nicolas Aguirre Mail: aguirre.nico...@gmail.com Web: http://enna.geexbox.org Blog: http://dev.enlightenment.fr/~captainigloo/ fix_gstreamer_configure_option.diff Description: Binary data -- 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. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
