Hello <lipens...@email.cz>,
Sorry, I couldn't write to you sooner.
(I'm not good at English.)
> 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.
I think so, too.
(After all, cygport utilities are an alternative method.)
> 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__" :)
My own opinions are as follows:
> Here are some issues:
> 1) Including win/linux header files such like <winsock2.h>
> e.g. #ifdef _WIN32 v.s #ifdef HAVE_WINSOCK2_H
Trying to keep OS specific ifdefs to the minimal amount.
But w32api headers can be included on windows regardless of
whether or not OS is cygwin.
AC_CHECK_HEADERS([winsock2.h])
|
V
checking winsock2.h usability... no
checking winsock2.h presence... yes
configure: WARNING: winsock2.h: present but cannot be compiled
configure: WARNING: winsock2.h: check for missing prerequisite headers?
configure: WARNING: winsock2.h: see the Autoconf documentation
configure: WARNING: winsock2.h: section "Present But Cannot Be Compiled"
configure: WARNING: winsock2.h: proceeding with the preprocessor's result
configure: WARNING: winsock2.h: in the future, the compiler will take
precedence
configure: WARNING: ## ------------------ ##
configure: WARNING: ## Report this to ... ##
configure: WARNING: ## ------------------ ##
checking for winsock2.h... yes
Therefore I suggest:
#if !defined(__CYGWIN__) // <- wrapped by __CYGWIN__ macro
#ifdef HAVE_WINSOCK2_H // <- using header specific macro
#include <winsock2.h>
#endif
#endif /* !defined(__CYGWIN__) */
> 2) Detecting an using shared library suffixes
> e.g. SHARED_LIB_SUFFIX (in ecore) v.s. #ifdef _WIN32 + ".dll" | ".so"
SHARED_LIB_SUFFIX is ideal detection method.
(To try to keep source files brief.)
> 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
Setting well-suited value to OS specific macros in header files.
I suggest:
/* 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.1&content-type=text/x-cvsweb-markup&cvsroot=src
> 4) Unix-like signal handling on windows (siginfo_t supported by cygwin
> but not by mingw)
Afterthinking about 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?
> Regards,
> Pavel
>
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
