X-Spam-Check-By: sourceware.org Subject: Re: portability notes From: skaller To: Eric Blake Cc: cygwin AT cygwin DOT com In-Reply-To: <43F3392A.2070102@byu.net> References: <1139902278 DOT 8591 DOT 581 DOT camel AT rosella DOT wigram> <43F3392A DOT 2070102 AT byu DOT net> Content-Type: text/plain Date: Thu, 16 Feb 2006 03:47:46 +1100 Message-Id: <1140022066.8591.888.camel@rosella.wigram> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com On Wed, 2006-02-15 at 07:22 -0700, Eric Blake wrote: > > CVS log entry for our systems says: > > > > * added WSAID_CONNECTEX and LPFN_CONNECTEX definitions for ming > > (nocygwin) target > > There is no such thing as ming - it is mingw or mingw32. Furthermore, > cygwin only provides -mno-cygwin as a convenience, but it is NOT SUPPORTED > on this list. Ask the mingw list instead. I wasn't asking for support/bug fixes or whatever -- I was asking for advice on the best programming practice to handle this kind of issue. > > * now conditionally define EAGAIN in posix compat layer because ming > > seems to have it. > > Why are you writing your own posix compat layer? Portability, reduced dependence on third party code, etc. > That is exactly what > cygwin is! Indeed! So there is not much work to do for Cygwin!! > Instead of targetting mingw, you could target cygwin and be > done with all those hacks. We're not targeting mingw. We're targetting Linux, Solaris, BSD, Cygwin, MinGW, Win32, Win64, OSX .. and any other platform we can get our code working on. The choice is up to the end user, not us. But I WOULD like to get rid of the hacks!! > > Any suggestions how to do this better? The API we're providing > > provides threads, events, and other such stuff on multiple > > platforms including Linux, Solaris, Win32 native, Cygwin, > > Cygwin with -mno-cygwin, MSYS/MinGW (maybe), OSX, BSD, etc. > > Compiling on cygwin with -mno-cygwin IS mingw. It generates the same binaries: indeed I can do that on my Linux box too, with a cross compiler. But it isn't the same platform. On cygwin, the build scripts can be written with bash, and the generated executables can be run and passed Unix filenames. With MingW or MSVC++ targets, executables have to be passed Windows filenames. Since our product is itself a cross-cross-compiler, these issues get nasty -- there are two stages of cross compilation. It took a long time to get this working right (and it may not be) So we're not just talking about compiling a simple application -- the application works like a scripting language, generates C++ instead of bytecode, which is then compiled to binaries and run -- and that's what happens *after* it is built. So, to give one of the original problems again: to emulate Posix on non-posix platforms, I found I had to define EAGAIN. I just did #ifdef _WIN32 #define EAGAIN TIMEOUT_WAIT #endif but then we found Mingw seems to define it too. So now the code reads: #ifdef _WIN32 #ifndef EAGAIN #define EAGAIN WAIT_TIMEOUT #endif #endif However it is a hack. It will do temporarily. A better solution would be to test if EAGAIN is already defined in the configuration script. Perhaps. The problem is that I don't know if it is a macro, and I don't know which file it might be defined in (on a non-posix system one can't assume it is in the standard place, indeed that idea seems like a contradiction). And its tricky to do if you're building the toolkit on a different platform from that on which the code will be run. > - -- > Life is short - so eat dessert first! I can live with that :) -- John Skaller Felix, successor to C++: http://felix.sf.net -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/