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 s.schm...@samsung.com 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 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
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 Mon, Feb 11, 2013 at 10:56 PM, Stefan Schmidt s.schm...@samsung.com 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
On Sat, 12 Jan 2013 09:26:13 +0100 Adrien Nader adr...@notk.org said: On Fri, Jan 11, 2013, Carsten Haitzler wrote: On Fri, 11 Jan 2013 13:59:48 +1000 David Seikel onef...@gmail.com said: On Fri, 11 Jan 2013 11:51:04 +0900 Cedric BAIL cedric.b...@free.fr wrote: On Fri, Jan 11, 2013 at 11:46 AM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 11 Jan 2013 09:46:42 +0900 Cedric BAIL cedric.b...@free.fr said: On Fri, Jan 11, 2013 at 9:26 AM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 11 Jan 2013 09:08:20 +0900 Cedric BAIL cedric.b...@free.fr said: On Fri, Jan 11, 2013 at 7:51 AM, Nicolas Aguirre aguirre.nico...@gmail.com wrote: After lucas commit, i tried to build EFL merge for win32. i configure with : ./configure --prefix=$MINGW_PREFIX --host=$TARGET --disable-static --with-tests=none --with-crypto=gnutls --disable-gstreamer --disable-pulseaudio --disable-audio --disable-physics --disable-gstreamer option does't work at all, it's ignored, attached a patch which fix this issue. The next issue is that the configure try to check for eeze, but eeze is a linux only package, it's a non sense for windows or macos. So how to remove eeze from the build ? It could be a good option to add a --disable-eeze option in the configure ? what you think about it ? Obviously, yes. I think we really need to setup a buildbot for mingw as the last serie of patch prove that nobody did test it at all and made change that are likely to break it. first... need to make a qemu vm for windows... and that means a windows licence/copy at a minimum. we should test a real build ON windows ... as opposed to a cross-compile. here's the question. windows xp, vista, 7 or 8? sure - in theory we should have all. in theory if we use xp... then what we build binary-wise AND the build itself should work on later versions too... At this point, just automated building will be a huge step forward... but we can't build on windows.. without a windows... install ... to build on. :P Cross compilation is faster as far as I know for windows :-) Vincent's Windows stuff was made to cross compile with mingw under Linux. That's the main delivery method he used. So no need for a Windows license to compile it. And as Cedric said, at least that means we can make sure compiling is not broken. Leave the result easily downloaded, and I'm sure people will download it to test it on their expensive Windows installs. but we can't make sure that compiling *ON* windows is not broken. we also can't verify if it runs properly or not (missing symbols, modules simply not loading at all etc.). Don't worry about missing symbols, there can be no undefined symbols in DLLs (that's in the design of the PE loader). Anyway, I get your point and I agree that's a goal but it's much more work. However it is *cross*-compilation which is way cleaner and nicer than compiling from something on windows. Various thoughts as bullet points: - building from cygwin to windows (not to cygwin) is cross-compilation - building from msys to windows (not to msys) is cross-compilation - msys is a big ugly hack (a fork of cygwin and a never-upstreamed fork of gcc 2.95 or 2.96 to add a specific target) - msys is a bastard in the first meaning of the name: it's a tentative mix of windows and posix, a guess of what comes from which, goes where and how it should be translated - buildbots on msys and cygwin will probably never be able to handle the load because of how slow they will be (iirc it took Vincent 10 times longer to build elementary from msys) and a ccache would probably make things worse - wine is working well enough to provide a good testing platform (I'm not saying that would replace tests on windows however) - vnc and rdesktop will have a much bigger impact on the rendering than wine - you can perfectly build on linux, test on windows and for that you can easily use the evaluation editions of windows; they have limitations but should be enough/perfect for tests tl;dr: msys and cygwin are cross-compilation anyway, both will make building too slow, msys is crap, wine is better than you seem to think and will make it possible to check the rendering and testing could be done through VMs with eval versions of windows. last time i ran elementary under wine: 1. font all missing 2. window kept moving down the screen by 1 titlebar height each time it .. rendered? or mouse entered? i dont remember... vincent reported that on windows it was fine - but not under wine. 3. build times i dont think are a problem... we will have the ram and cpu power to throw at it. yes - cross-build on linux
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 adr...@notk.org said: On Fri, Jan 11, 2013, Carsten Haitzler wrote: On Fri, 11 Jan 2013 13:59:48 +1000 David Seikel onef...@gmail.com said: On Fri, 11 Jan 2013 11:51:04 +0900 Cedric BAIL cedric.b...@free.fr wrote: On Fri, Jan 11, 2013 at 11:46 AM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 11 Jan 2013 09:46:42 +0900 Cedric BAIL cedric.b...@free.fr said: On Fri, Jan 11, 2013 at 9:26 AM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 11 Jan 2013 09:08:20 +0900 Cedric BAIL cedric.b...@free.fr said: On Fri, Jan 11, 2013 at 7:51 AM, Nicolas Aguirre aguirre.nico...@gmail.com wrote: After lucas commit, i tried to build EFL merge for win32. i configure with : ./configure --prefix=$MINGW_PREFIX --host=$TARGET --disable-static --with-tests=none --with-crypto=gnutls --disable-gstreamer --disable-pulseaudio --disable-audio --disable-physics --disable-gstreamer option does't work at all, it's ignored, attached a patch which fix this issue. The next issue is that the configure try to check for eeze, but eeze is a linux only package, it's a non sense for windows or macos. So how to remove eeze from the build ? It could be a good option to add a --disable-eeze option in the configure ? what you think about it ? Obviously, yes. I think we really need to setup a buildbot for mingw as the last serie of patch prove that nobody did test it at all and made change that are likely to break it. first... need to make a qemu vm for windows... and that means a windows licence/copy at a minimum. we should test a real build ON windows ... as opposed to a cross-compile. here's the question. windows xp, vista, 7 or 8? sure - in theory we should have all. in theory if we use xp... then what we build binary-wise AND the build itself should work on later versions too... At this point, just automated building will be a huge step forward... but we can't build on windows.. without a windows... install ... to build on. :P Cross compilation is faster as far as I know for windows :-) Vincent's Windows stuff was made to cross compile with mingw under Linux. That's the main delivery method he used. So no need for a Windows license to compile it. And as Cedric said, at least that means we can make sure compiling 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! ;-) /joke 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_122612 ___ 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 Mon, Jan 14, 2013 at 4:53 AM, Nicolas Aguirre aguirre.nico...@gmail.com wrote: 2013/1/11 Gustavo Sverzut Barbieri barbi...@profusion.mobi On Fri, Jan 11, 2013 at 4:43 PM, Nicolas Aguirre aguirre.nico...@gmail.com 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 dllexport attribute: dllimport ignored [-Wattributes]
Re: [E-devel] efl merge and win32
On Mon, Jan 14, 2013 at 7:51 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Mon, Jan 14, 2013 at 4:53 AM, Nicolas Aguirre aguirre.nico...@gmail.com wrote: 2013/1/11 Gustavo Sverzut Barbieri barbi...@profusion.mobi On Fri, Jan 11, 2013 at 4:43 PM, Nicolas Aguirre aguirre.nico...@gmail.com 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:
Re: [E-devel] efl merge and win32
On Mon, Jan 14, 2013 at 12:03 PM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 14, 2013 at 7:51 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Mon, Jan 14, 2013 at 4:53 AM, Nicolas Aguirre aguirre.nico...@gmail.com wrote: 2013/1/11 Gustavo Sverzut Barbieri barbi...@profusion.mobi On Fri, Jan 11, 2013 at 4:43 PM, Nicolas Aguirre aguirre.nico...@gmail.com 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]
Re: [E-devel] efl merge and win32
On Mon, Jan 14, 2013 at 12:03 PM, Cedric BAIL cedric.b...@free.fr wrote: On Mon, Jan 14, 2013 at 7:51 PM, Gustavo Sverzut Barbieri barbi...@profusion.mobi wrote: On Mon, Jan 14, 2013 at 4:53 AM, Nicolas Aguirre aguirre.nico...@gmail.com wrote: 2013/1/11 Gustavo Sverzut Barbieri barbi...@profusion.mobi On Fri, Jan 11, 2013 at 4:43 PM, Nicolas Aguirre aguirre.nico...@gmail.com 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]
Re: [E-devel] efl merge and win32
2013/1/11 Gustavo Sverzut Barbieri barbi...@profusion.mobi On Fri, Jan 11, 2013 at 4:43 PM, Nicolas Aguirre aguirre.nico...@gmail.com 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:
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 onef...@gmail.com said: On Fri, 11 Jan 2013 11:51:04 +0900 Cedric BAIL cedric.b...@free.fr wrote: On Fri, Jan 11, 2013 at 11:46 AM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 11 Jan 2013 09:46:42 +0900 Cedric BAIL cedric.b...@free.fr said: On Fri, Jan 11, 2013 at 9:26 AM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 11 Jan 2013 09:08:20 +0900 Cedric BAIL cedric.b...@free.fr said: On Fri, Jan 11, 2013 at 7:51 AM, Nicolas Aguirre aguirre.nico...@gmail.com wrote: After lucas commit, i tried to build EFL merge for win32. i configure with : ./configure --prefix=$MINGW_PREFIX --host=$TARGET --disable-static --with-tests=none --with-crypto=gnutls --disable-gstreamer --disable-pulseaudio --disable-audio --disable-physics --disable-gstreamer option does't work at all, it's ignored, attached a patch which fix this issue. The next issue is that the configure try to check for eeze, but eeze is a linux only package, it's a non sense for windows or macos. So how to remove eeze from the build ? It could be a good option to add a --disable-eeze option in the configure ? what you think about it ? Obviously, yes. I think we really need to setup a buildbot for mingw as the last serie of patch prove that nobody did test it at all and made change that are likely to break it. first... need to make a qemu vm for windows... and that means a windows licence/copy at a minimum. we should test a real build ON windows ... as opposed to a cross-compile. here's the question. windows xp, vista, 7 or 8? sure - in theory we should have all. in theory if we use xp... then what we build binary-wise AND the build itself should work on later versions too... At this point, just automated building will be a huge step forward... but we can't build on windows.. without a windows... install ... to build on. :P Cross compilation is faster as far as I know for windows :-) Vincent's Windows stuff was made to cross compile with mingw under Linux. That's the main delivery method he used. So no need for a Windows license to compile it. And as Cedric said, at least that means we can make sure compiling is not broken. Leave the result easily downloaded, and I'm sure people will download it to test it on their expensive Windows installs. but we can't make sure that compiling *ON* windows is not broken. we also can't verify if it runs properly or not (missing symbols, modules simply not loading at all etc.). Don't worry about missing symbols, there can be no undefined symbols in DLLs (that's in the design of the PE loader). Anyway, I get your point and I agree that's a goal but it's much more work. However it is *cross*-compilation which is way cleaner and nicer than compiling from something on windows. Various thoughts as bullet points: - building from cygwin to windows (not to cygwin) is cross-compilation - building from msys to windows (not to msys) is cross-compilation - msys is a big ugly hack (a fork of cygwin and a never-upstreamed fork of gcc 2.95 or 2.96 to add a specific target) - msys is a bastard in the first meaning of the name: it's a tentative mix of windows and posix, a guess of what comes from which, goes where and how it should be translated - buildbots on msys and cygwin will probably never be able to handle the load because of how slow they will be (iirc it took Vincent 10 times longer to build elementary from msys) and a ccache would probably make things worse - wine is working well enough to provide a good testing platform (I'm not saying that would replace tests on windows however) - vnc and rdesktop will have a much bigger impact on the rendering than wine - you can perfectly build on linux, test on windows and for that you can easily use the evaluation editions of windows; they have limitations but should be enough/perfect for tests tl;dr: msys and cygwin are cross-compilation anyway, both will make building too slow, msys is crap, wine is better than you seem to think and will make it possible to check the rendering and testing could be done through VMs with eval versions of windows. -- Adrien Nader -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122912 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net
Re: [E-devel] efl merge and win32
On Friday, January 11, 2013, Nicolas Aguirre wrote:
2013/1/11 Gustavo Sverzut Barbieri barbi...@profusion.mobi javascript:;
On Thu, Jan 10, 2013 at 8:51 PM, Nicolas Aguirre
aguirre.nico...@gmail.com javascript:;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 javascript:;
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 javascript:;
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 barbi...@profusion.mobi
On Friday, January 11, 2013, Nicolas Aguirre wrote:
2013/1/11 Gustavo Sverzut Barbieri barbi...@profusion.mobijavascript:;
On Thu, Jan 10, 2013 at 8:51 PM, Nicolas Aguirre
aguirre.nico...@gmail.com javascript:;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 javascript:;
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 javascript:;
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 Fri, Jan 11, 2013 at 2:55 PM, Nicolas Aguirre
aguirre.nico...@gmail.com wrote:
2013/1/11 Gustavo Sverzut Barbieri barbi...@profusion.mobi
On Friday, January 11, 2013, Nicolas Aguirre wrote:
2013/1/11 Gustavo Sverzut Barbieri barbi...@profusion.mobijavascript:;
On Thu, Jan 10, 2013 at 8:51 PM, Nicolas Aguirre
aguirre.nico...@gmail.com javascript:;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 barbi...@profusion.mobi
On Fri, Jan 11, 2013 at 2:55 PM, Nicolas Aguirre
aguirre.nico...@gmail.com wrote:
2013/1/11 Gustavo Sverzut Barbieri barbi...@profusion.mobi
On Friday, January 11, 2013, Nicolas Aguirre wrote:
2013/1/11 Gustavo Sverzut Barbieri barbi...@profusion.mobi
javascript:;
On Thu, Jan 10, 2013 at 8:51 PM, Nicolas Aguirre
aguirre.nico...@gmail.com javascript:;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
Pixman Images...: no
Pixman Image ScaleSample: no
Conversion Options:
Dither Mask.: big
Tiled 32BPP rotate..: no
Ecore:
GLib support...: no
Use g_main_loop: no
Gathering memory statistic.: no
Gathering timer allocation.: no
Re: [E-devel] efl merge and win32
On Fri, Jan 11, 2013 at 4:43 PM, Nicolas Aguirre aguirre.nico...@gmail.com 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
[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
Re: [E-devel] efl merge and win32
Yop, On Fri, Jan 11, 2013 at 7:51 AM, Nicolas Aguirre aguirre.nico...@gmail.com wrote: After lucas commit, i tried to build EFL merge for win32. i configure with : ./configure --prefix=$MINGW_PREFIX --host=$TARGET --disable-static --with-tests=none --with-crypto=gnutls --disable-gstreamer --disable-pulseaudio --disable-audio --disable-physics --disable-gstreamer option does't work at all, it's ignored, attached a patch which fix this issue. The next issue is that the configure try to check for eeze, but eeze is a linux only package, it's a non sense for windows or macos. So how to remove eeze from the build ? It could be a good option to add a --disable-eeze option in the configure ? what you think about it ? Obviously, yes. I think we really need to setup a buildbot for mingw as the last serie of patch prove that nobody did test it at all and made change that are likely to break it. -- 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 cedric.b...@free.fr said: Yop, On Fri, Jan 11, 2013 at 7:51 AM, Nicolas Aguirre aguirre.nico...@gmail.com wrote: After lucas commit, i tried to build EFL merge for win32. i configure with : ./configure --prefix=$MINGW_PREFIX --host=$TARGET --disable-static --with-tests=none --with-crypto=gnutls --disable-gstreamer --disable-pulseaudio --disable-audio --disable-physics --disable-gstreamer option does't work at all, it's ignored, attached a patch which fix this issue. The next issue is that the configure try to check for eeze, but eeze is a linux only package, it's a non sense for windows or macos. So how to remove eeze from the build ? It could be a good option to add a --disable-eeze option in the configure ? what you think about it ? Obviously, yes. I think we really need to setup a buildbot for mingw as the last serie of patch prove that nobody did test it at all and made change that are likely to break it. first... need to make a qemu vm for windows... and that means a windows licence/copy at a minimum. we should test a real build ON windows ... as opposed to a cross-compile. here's the question. windows xp, vista, 7 or 8? sure - in theory we should have all. in theory if we use xp... then what we build binary-wise AND the build itself should work on later versions too... -- - 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 ras...@rasterman.com wrote: On Fri, 11 Jan 2013 09:08:20 +0900 Cedric BAIL cedric.b...@free.fr said: On Fri, Jan 11, 2013 at 7:51 AM, Nicolas Aguirre aguirre.nico...@gmail.com wrote: After lucas commit, i tried to build EFL merge for win32. i configure with : ./configure --prefix=$MINGW_PREFIX --host=$TARGET --disable-static --with-tests=none --with-crypto=gnutls --disable-gstreamer --disable-pulseaudio --disable-audio --disable-physics --disable-gstreamer option does't work at all, it's ignored, attached a patch which fix this issue. The next issue is that the configure try to check for eeze, but eeze is a linux only package, it's a non sense for windows or macos. So how to remove eeze from the build ? It could be a good option to add a --disable-eeze option in the configure ? what you think about it ? Obviously, yes. I think we really need to setup a buildbot for mingw as the last serie of patch prove that nobody did test it at all and made change that are likely to break it. first... need to make a qemu vm for windows... and that means a windows licence/copy at a minimum. we should test a real build ON windows ... as opposed to a cross-compile. here's the question. windows xp, vista, 7 or 8? sure - in theory we should have all. in theory if we use xp... then what we build binary-wise AND the build itself should work on later versions too... At this point, just automated building will be a huge step forward... -- 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 cedric.b...@free.fr said: On Fri, Jan 11, 2013 at 9:26 AM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 11 Jan 2013 09:08:20 +0900 Cedric BAIL cedric.b...@free.fr said: On Fri, Jan 11, 2013 at 7:51 AM, Nicolas Aguirre aguirre.nico...@gmail.com wrote: After lucas commit, i tried to build EFL merge for win32. i configure with : ./configure --prefix=$MINGW_PREFIX --host=$TARGET --disable-static --with-tests=none --with-crypto=gnutls --disable-gstreamer --disable-pulseaudio --disable-audio --disable-physics --disable-gstreamer option does't work at all, it's ignored, attached a patch which fix this issue. The next issue is that the configure try to check for eeze, but eeze is a linux only package, it's a non sense for windows or macos. So how to remove eeze from the build ? It could be a good option to add a --disable-eeze option in the configure ? what you think about it ? Obviously, yes. I think we really need to setup a buildbot for mingw as the last serie of patch prove that nobody did test it at all and made change that are likely to break it. first... need to make a qemu vm for windows... and that means a windows licence/copy at a minimum. we should test a real build ON windows ... as opposed to a cross-compile. here's the question. windows xp, vista, 7 or 8? sure - in theory we should have all. in theory if we use xp... then what we build binary-wise AND the build itself should work on later versions too... At this point, just automated building will be a huge step forward... but we can't build on windows.. without a windows... install ... to build on. :P -- - 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 11:46 AM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 11 Jan 2013 09:46:42 +0900 Cedric BAIL cedric.b...@free.fr said: On Fri, Jan 11, 2013 at 9:26 AM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 11 Jan 2013 09:08:20 +0900 Cedric BAIL cedric.b...@free.fr said: On Fri, Jan 11, 2013 at 7:51 AM, Nicolas Aguirre aguirre.nico...@gmail.com wrote: After lucas commit, i tried to build EFL merge for win32. i configure with : ./configure --prefix=$MINGW_PREFIX --host=$TARGET --disable-static --with-tests=none --with-crypto=gnutls --disable-gstreamer --disable-pulseaudio --disable-audio --disable-physics --disable-gstreamer option does't work at all, it's ignored, attached a patch which fix this issue. The next issue is that the configure try to check for eeze, but eeze is a linux only package, it's a non sense for windows or macos. So how to remove eeze from the build ? It could be a good option to add a --disable-eeze option in the configure ? what you think about it ? Obviously, yes. I think we really need to setup a buildbot for mingw as the last serie of patch prove that nobody did test it at all and made change that are likely to break it. first... need to make a qemu vm for windows... and that means a windows licence/copy at a minimum. we should test a real build ON windows ... as opposed to a cross-compile. here's the question. windows xp, vista, 7 or 8? sure - in theory we should have all. in theory if we use xp... then what we build binary-wise AND the build itself should work on later versions too... At this point, just automated building will be a huge step forward... but we can't build on windows.. without a windows... install ... to build on. :P Cross compilation is faster as far as I know for windows :-) -- 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 Thu, Jan 10, 2013 at 8:51 PM, Nicolas Aguirre
aguirre.nico...@gmail.comwrote:
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, 11 Jan 2013 11:51:04 +0900 Cedric BAIL cedric.b...@free.fr wrote: On Fri, Jan 11, 2013 at 11:46 AM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 11 Jan 2013 09:46:42 +0900 Cedric BAIL cedric.b...@free.fr said: On Fri, Jan 11, 2013 at 9:26 AM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 11 Jan 2013 09:08:20 +0900 Cedric BAIL cedric.b...@free.fr said: On Fri, Jan 11, 2013 at 7:51 AM, Nicolas Aguirre aguirre.nico...@gmail.com wrote: After lucas commit, i tried to build EFL merge for win32. i configure with : ./configure --prefix=$MINGW_PREFIX --host=$TARGET --disable-static --with-tests=none --with-crypto=gnutls --disable-gstreamer --disable-pulseaudio --disable-audio --disable-physics --disable-gstreamer option does't work at all, it's ignored, attached a patch which fix this issue. The next issue is that the configure try to check for eeze, but eeze is a linux only package, it's a non sense for windows or macos. So how to remove eeze from the build ? It could be a good option to add a --disable-eeze option in the configure ? what you think about it ? Obviously, yes. I think we really need to setup a buildbot for mingw as the last serie of patch prove that nobody did test it at all and made change that are likely to break it. first... need to make a qemu vm for windows... and that means a windows licence/copy at a minimum. we should test a real build ON windows ... as opposed to a cross-compile. here's the question. windows xp, vista, 7 or 8? sure - in theory we should have all. in theory if we use xp... then what we build binary-wise AND the build itself should work on later versions too... At this point, just automated building will be a huge step forward... but we can't build on windows.. without a windows... install ... to build on. :P Cross compilation is faster as far as I know for windows :-) Vincent's Windows stuff was made to cross compile with mingw under Linux. That's the main delivery method he used. So no need for a Windows license to compile it. And as Cedric said, at least that means we can make sure compiling is not broken. Leave the result easily downloaded, and I'm sure people will download it to test it on their expensive Windows installs. 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 Fri, 11 Jan 2013 13:59:48 +1000 David Seikel onef...@gmail.com said: On Fri, 11 Jan 2013 11:51:04 +0900 Cedric BAIL cedric.b...@free.fr wrote: On Fri, Jan 11, 2013 at 11:46 AM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 11 Jan 2013 09:46:42 +0900 Cedric BAIL cedric.b...@free.fr said: On Fri, Jan 11, 2013 at 9:26 AM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 11 Jan 2013 09:08:20 +0900 Cedric BAIL cedric.b...@free.fr said: On Fri, Jan 11, 2013 at 7:51 AM, Nicolas Aguirre aguirre.nico...@gmail.com wrote: After lucas commit, i tried to build EFL merge for win32. i configure with : ./configure --prefix=$MINGW_PREFIX --host=$TARGET --disable-static --with-tests=none --with-crypto=gnutls --disable-gstreamer --disable-pulseaudio --disable-audio --disable-physics --disable-gstreamer option does't work at all, it's ignored, attached a patch which fix this issue. The next issue is that the configure try to check for eeze, but eeze is a linux only package, it's a non sense for windows or macos. So how to remove eeze from the build ? It could be a good option to add a --disable-eeze option in the configure ? what you think about it ? Obviously, yes. I think we really need to setup a buildbot for mingw as the last serie of patch prove that nobody did test it at all and made change that are likely to break it. first... need to make a qemu vm for windows... and that means a windows licence/copy at a minimum. we should test a real build ON windows ... as opposed to a cross-compile. here's the question. windows xp, vista, 7 or 8? sure - in theory we should have all. in theory if we use xp... then what we build binary-wise AND the build itself should work on later versions too... At this point, just automated building will be a huge step forward... but we can't build on windows.. without a windows... install ... to build on. :P Cross compilation is faster as far as I know for windows :-) Vincent's Windows stuff was made to cross compile with mingw under Linux. That's the main delivery method he used. So no need for a Windows license to compile it. And as Cedric said, at least that means we can make sure compiling is not broken. Leave the result easily downloaded, and I'm sure people will download it to test it on their expensive Windows installs. but we can't make sure that compiling *ON* windows is not broken. we also can't verify if it runs properly or not (missing symbols, modules simply not loading at all etc.). 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 14:14:38 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Fri, 11 Jan 2013 13:59:48 +1000 David Seikel onef...@gmail.com said: On Fri, 11 Jan 2013 11:51:04 +0900 Cedric BAIL cedric.b...@free.fr wrote: On Fri, Jan 11, 2013 at 11:46 AM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 11 Jan 2013 09:46:42 +0900 Cedric BAIL cedric.b...@free.fr said: On Fri, Jan 11, 2013 at 9:26 AM, Carsten Haitzler ras...@rasterman.com wrote: On Fri, 11 Jan 2013 09:08:20 +0900 Cedric BAIL cedric.b...@free.fr said: On Fri, Jan 11, 2013 at 7:51 AM, Nicolas Aguirre aguirre.nico...@gmail.com wrote: After lucas commit, i tried to build EFL merge for win32. i configure with : ./configure --prefix=$MINGW_PREFIX --host=$TARGET --disable-static --with-tests=none --with-crypto=gnutls --disable-gstreamer --disable-pulseaudio --disable-audio --disable-physics --disable-gstreamer option does't work at all, it's ignored, attached a patch which fix this issue. The next issue is that the configure try to check for eeze, but eeze is a linux only package, it's a non sense for windows or macos. So how to remove eeze from the build ? It could be a good option to add a --disable-eeze option in the configure ? what you think about it ? Obviously, yes. I think we really need to setup a buildbot for mingw as the last serie of patch prove that nobody did test it at all and made change that are likely to break it. first... need to make a qemu vm for windows... and that means a windows licence/copy at a minimum. we should test a real build ON windows ... as opposed to a cross-compile. here's the question. windows xp, vista, 7 or 8? sure - in theory we should have all. in theory if we use xp... then what we build binary-wise AND the build itself should work on later versions too... At this point, just automated building will be a huge step forward... but we can't build on windows.. without a windows... install ... to build on. :P Cross compilation is faster as far as I know for windows :-) Vincent's Windows stuff was made to cross compile with mingw under Linux. That's the main delivery method he used. So no need for a Windows license to compile it. And as Cedric said, at least that means we can make sure compiling is not broken. Leave the result easily downloaded, and I'm sure people will download it to test it on their expensive Windows installs. but we can't make sure that compiling *ON* windows is not broken. we also can't verify if it runs properly or not (missing symbols, modules simply not loading at all etc.). 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 at: http://p.sf.net/sfu/learnmore_122812___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net
Re: [E-devel] efl merge and win32
2013/1/11 Carsten Haitzler ras...@rasterman.com On Fri, 11 Jan 2013 09:08:20 +0900 Cedric BAIL cedric.b...@free.fr said: Yop, On Fri, Jan 11, 2013 at 7:51 AM, Nicolas Aguirre aguirre.nico...@gmail.com wrote: After lucas commit, i tried to build EFL merge for win32. i configure with : ./configure --prefix=$MINGW_PREFIX --host=$TARGET --disable-static --with-tests=none --with-crypto=gnutls --disable-gstreamer --disable-pulseaudio --disable-audio --disable-physics --disable-gstreamer option does't work at all, it's ignored, attached a patch which fix this issue. The next issue is that the configure try to check for eeze, but eeze is a linux only package, it's a non sense for windows or macos. So how to remove eeze from the build ? It could be a good option to add a --disable-eeze option in the configure ? what you think about it ? Obviously, yes. I think we really need to setup a buildbot for mingw as the last serie of patch prove that nobody did test it at all and made change that are likely to break it. first... need to make a qemu vm for windows... and that means a windows licence/copy at a minimum. we should test a real build ON windows ... as opposed to a cross-compile. here's the question. windows xp, vista, 7 or 8? sure - in theory we should have all. in theory if we use xp... then what we build binary-wise AND the build itself should work on later versions too... 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
2013/1/11 Gustavo Sverzut Barbieri barbi...@profusion.mobi
On Thu, Jan 10, 2013 at 8:51 PM, Nicolas Aguirre
aguirre.nico...@gmail.comwrote:
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
