This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: portability notes


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 <skaller at users dot sf dot net>
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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]