Re: [E-devel] E17 on Cygwin/X platform?
Hi booleanla...@gmail.com, Sorry, I couldn't write to you sooner. (I'm not good at English.) Me, neither :) Regarding winsock2.h AC_CHECK_HEADERS([winsock2.h]) #if !defined(__CYGWIN__) // - wrapped by __CYGWIN__ macro #ifdef HAVE_WINSOCK2_H // - using header specific macro #include winsock2.h #endif #endif /* !defined(__CYGWIN__) */ I would rather handle all the stuff by config.h file and force AC_DEFINE(HAVE_WINSOCK2_H, 0) in cygwin section if needed. Additionally it would be nice to unify the directives among all the components. I think, the current status of #include winsock2.h is not very nice. Eet #if defined(_WIN32) ! defined(__CEGCC__) Ecore (inecore_ipc.c, ecore_ipc) #ifdef HAVE_WINSOCK2_H (but never configured ???) Ecore (ecore_main.c) #ifdef _WIN32 3) Handing OS specific defines such like _POSIX_PATH_MAX e.g. /* embryo_cc_osdefs.h */ #if defined(__CYGWIN__) // wrapped by __CYGWIN__ // because cygwin-patches should not // affect compilation on other platforms #if !defined(_POSIX_PATH_MAX) #define _POSIX_PATH_MAX 255 #endif /* !defined(_POSIX_PATH_MAX) */ #endif /* defined(__CYGWIN__) */ FYI: _POSIX_PATH_MAX has already supported from the initial release by /usr/include/limits.h http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/limits.h?rev=1.1content-type=text/x-cvsweb-markupcvsroot=src I am sorry, _POSIX_PATH_MAX is fine (embryo_cc_osdefs.h includes limits.h), but _POSIX_HOST_NAME_MAX does not exist on Cygwin at all. Therefore I suggest to use #ifdef(__CYGWIN__) // fixing missing define in limints.h #ifndef _POSIX_HOST_NAME_MAX // which could be supported later #define _POSIX_HOST_NAME_MAX 255 #endif #endif close to the beginning of both the e_fm.c and efreet_uri.c files. 4) Unix-like signal handling on windows (siginfo_t supported by cygwin but not by mingw) I think it isn't so serious problem because cygwin supports most of Unix-like signal handling feature to compile Unix-based source files. Or do you want to compile e17 even on mingw? No, I am only interested in Cygwin/X now. I remember I did a lot of dirty patches in E17/043 (severa l#ifndef _WIN32 replacements in Ecore.h, ecore_exe.c, ecore_sginal.c, etc.) in order to use siginfo_t type and Unix-based signal handling. With these changes, the process termination worked much more better. Especially when running E17 for several days, there were no zombie tasks (such like many sh.exe, bash.exe) visible in MS Task Manager. Now I would rather prefer to configure it e.g. by HAVE_SIGNAL_H (disabled on mingw an cegcc because of the missing siginfo_t) rather then using pure #if defined _WIN32 || defined __CYGWIN__ directive. but this is just a religion, it depends on dev conventions :) Best regards, Pavel -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17 on Cygwin/X platform?
Hi booleanla...@gmail.com, good news you are are still working on Cygwin/X port. I remember your 042 experimental release half a year ago, which really helped me. But then the link became unreachable and/or blocked :( When updating Cygwin components, the X libraries were moved and my customized E17/043 stopped working :( I decided to port 050 snapshot myself from scratch, instead of recompiling the old one. Regarding the changes in 050 snapshot, I don't thing our patches differ semantically so much. Generally we are both fixing the same things, trying not to affect exiting platforms. I would personally prefer the Cygwin/X to be natively supported in SVN repository, instead of using cygport utilities for every new snapshot. It is probably not possible to move all the changes at once. But what about to do it incrementally, step by step, component by component starting e.g. with updating Makefiles.in and configure.ac by adding your cygwin section and using AC_LIBTOOL_WIN32_DLL and -no-undefined linking flag ??? I currently don't know how the EFL-E17 devel processes look like (I mean commitments, testing, reviews, knowledge base, etc.), and how to join the team. However on some places in the code I would suggest to unify platform dependent directives among the component to improve the portability and to avoid so many directives such like #if defined _WIN32 || ! defined __CYGWIN__ :) Here are some issues: 1) Including win/linux header files such like winsock2.h e.g. #ifdef _WIN32 v.s #ifdef HAVE_WINSOCK2_H 2) Detecting an using shared library suffixes e.g. SHARED_LIB_SUFFIX (in ecore) v.s. #ifdef _WIN32 + .dll | .so 3) Handing OS specific defines such like _POSIX_PATH_MAX e.g. embryo_cc_osdefs.h v.s. #ifdef in C files v.s. not defined 4) Unix-like signal handling on windows (siginfo_t supported by cygwin but not by mingw) Regards, Pavel Původní zpráva Od: booleanla...@gmail.com Předmět: Re: [E-devel] E17 on Cygwin/X platform? Datum: 24.12.2008 16:07:22 Hello lipens...@email.cz, I'm trying to compile e17 for cygwin, too. I upload e17 packages of snapshot(2008-09-25). http://fd0.x0.to/cygwin/release/ *-src.tar.bz2 contains my patches to compile on cygwin. (My patches differ from yours.) I hope you find them informative. Best regards -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E17 on Cygwin/X platform?
Původní zpráva Od: Nick Hughart mek...@mekius.net Předmět: Re: [E-devel] E17 on Cygwin/X platform? Datum: 19.12.2008 19:05:28 On Thu, 18 Dec 2008 15:39:39 +0100 (CET) Pavel Lipenský lipens...@email.cz wrote: Hi Chaps, many thanks for great job on E16/E17 !!! I've been mad about using Enlightenment for many years, starting E16 on Linux. I've been working as a SW engineer for almost 6 year, focusing of Unix/Linux development, but currently I have to use WinXP host OS in the office :( I did some changes in my free time to make E17 running on Cygwin. There are still some problems, but X11_SW and XRENDER_X11 engine works fine, GL_X11 partly but stable. See screenshots (small one from 043 snapshot, big one from 050), and let me know if you interested in changes. I would like to contribute. Best regards, Pavel Lipensky PS: Changes briefly They were mostly about adding Cygwin section into configure.in files and about updating Makefiles.am files with @lt_no_undefined@ to link DLLs correctly. Otherwise there were only minority changes needed in sources (such like extending some #ifdef _WIN32), Well, except of two issues - adding possibility to building E17 as a library in order to link e_modules on Windows. - small hack of the local E_IPC to use AF_INET instead of broken unix sockets (due to naming restrictions on NTFS, and mainly due to blocking when accepting more clients) Your files got lost probably due to improper mimetypes, you may need to post them somewhere online and provide links. See http://www.lip.wz.cz/e17/ -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] E17 on Cygwin/X platform?
Hi Chaps, many thanks for great job on E16/E17 !!! I've been mad about using Enlightenment for many years, starting E16 on Linux. I've been working as a SW engineer for almost 6 year, focusing of Unix/Linux development, but currently I have to use WinXP host OS in the office :( I did some changes in my free time to make E17 running on Cygwin. There are still some problems, but X11_SW and XRENDER_X11 engine works fine, GL_X11 partly but stable. See screenshots (small one from 043 snapshot, big one from 050), and let me know if you interested in changes. I would like to contribute. Best regards, Pavel Lipensky PS: Changes briefly They were mostly about adding Cygwin section into configure.in files and about updating Makefiles.am files with @lt_no_undefined@ to link DLLs correctly. Otherwise there were only minority changes needed in sources (such like extending some #ifdef _WIN32), Well, except of two issues - adding possibility to building E17 as a library in order to link e_modules on Windows. - small hack of the local E_IPC to use AF_INET instead of broken unix sockets (due to naming restrictions on NTFS, and mainly due to blocking when accepting more clients) -- ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
