Beman Dawes wrote:
On Thu, Jan 6, 2011 at 4:32 PM, vicente.botet <vicente.botet@wanadoo.fr> wrote:
Hi,
while trying to make Boost.System and Boost.Chrono configurable header only libs we need to include windows.h on some include files. To avoid the inclusion of this intrusive file, we decided sometime ago to include some files in detail/win that will present just the needed interfaces.
In my humble opinion cygwin is a wrapper of posix intefaces under windows OS.
Cygwin is a distribution, not an API. The Cygwin distribution includes both the POSIX API and, via MinGW, the Windows API.
There are different opinions of what cygwin really means. Where I am, most folks believe that Cygwin is a flavour of GNU operating system, which happens to use Windows kernel somewhere deep inside, and provides POSIX API. Also, where I am, most folks are scared of that strange creature.
<aside> The POSIX API is implemented by calling the Windows API, so is really only an emulation of POSIX. It does a great job, but is weak in a few areas, such as permissions, where the Windows API doesn't allow 100% emulation of POSIX. </aside>
So, boost libraries shouldn't use Windows interfaces when working under cygwin.
That doesn't follow. A primary use of Cygwin is simply to gain access to GCC on Windows, without any intent to ever port code to POSIX systems, and without any interest in, or knowledge of, the POSIX API.
I think you'd just use mingw for that? Which is smaller for starters. Cygwin is only sensible if you actually want GNU operating system, including your familiar (ba)sh prompt, and a pack of various command-line tools.
This use has become more popular as GCC has jumped far ahead of VC++ in terms of C++0x support.
Another primary use of Cygwin is to gain access to GCC and the POSIX API on Windows, but that doesn't imply anything about what Boost implementations should do.
What's the experience of others?
Boost.Filesystem V2 implementation code provided an option on Windows of compiling under GCC using the POSIX API. It was difficult to test, rarely worked well, was a source of confusion, and wasted too much of my time. So Filesystem V3 and Boost.System dropped any pretense of compiling with the POSIX API on Windows. There have been no complaints so far.
Boost.System only uses a very few O/S API calls, so it would be relatively easy to compile for the Cygwin supplied POSIX API on Windows. But there have been no requests, so far.
I don't have any comments about whether it's worthwhile for any specific library to support cygwin-the-api, but I would really suggest to treat Cygwin as a different operating system, and entirely forget there's Windows somewhere beyond. - Volodya