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. So, boost libraries shouldn't use Windows interfaces when working under cygwin. What's the experience of others? Best, Vicente
vicente.botet wrote:
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. So, boost libraries shouldn't use Windows interfaces when working under cygwin.
We don't use cygwin for our Windows code. Can the POSIX support be installed and used without running in cygwin? If not, this is a non-starter. If so, then it would be another burden to use such Boost libraries, though perhaps it's simple enough to arrange. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
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. <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. 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. --Beman
On 1:59 PM, Beman Dawes wrote:
On Thu, Jan 6, 2011 at 4:32 PM, vicente.botet <vicente.botet@wanadoo.fr> wrote:
Hi,
[...]
In my humble opinion cygwin is a wrapper of posix intefaces under windows OS. [...]
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.
FWIW, I vaguely recall some time ago trying to get a straight-CygWin regression test going. (Or was it just building boost?) It didn't go well and I bagged it: paths were coming out in both CygWin (correctly: /cygdrive/c/...) and Windows native ('C:\...'), and I couldn't quite track it down to a single point of failure. As another aside, CygWin's license is much less desirable than MinGW's: <http://tinyurl.com/npkref>
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
On Thu, 06 Jan 2011 22:32:16 +0100, 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. So, boost libraries shouldn't use Windows interfaces when working under cygwin.
What's the experience of others?
The last time I played around with the Boost libraries on Cygwin (that was in 2008) the Windows API was used by default. Building the libraries with "bjam cxxflags=-DBOOST_POSIX_API" was enough though to use the POSIX API. Whether that worked for all libraries I don't remember anymore (I only remember that the Boost.Process draft at that time could only be built with the POSIX API on Cygwin). Being able to use both APIs and simply switching with a macro seemed pretty good though? Boris
----- Original Message ----- From: "Boris Schaeling" <boris@highscore.de> To: <boost@lists.boost.org> Sent: Saturday, January 08, 2011 11:19 AM Subject: Re: [boost] cygwin API: posix or windows
On Thu, 06 Jan 2011 22:32:16 +0100, 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. So, boost libraries shouldn't use Windows interfaces when working under cygwin.
What's the experience of others?
The last time I played around with the Boost libraries on Cygwin (that was in 2008) the Windows API was used by default. Building the libraries with "bjam cxxflags=-DBOOST_POSIX_API" was enough though to use the POSIX API. Whether that worked for all libraries I don't remember anymore (I only remember that the Boost.Process draft at that time could only be built with the POSIX API on Cygwin). Being able to use both APIs and simply switching with a macro seemed pretty good though?
If I'm not wrong, BOOST_POSIX_API is used only by Boost.System and Boost.Filesystem boost libraries (that is the Beman system libraries). I think the definition of this macro should be moved to the Boost.Config library or renames BOOST_SYSTEM_POSIX_API. Other system libraries like Boost.Thread are not using this to select the API, in fact Boost.Thread uses the posix api. When the used API is hidden on the lib/XXX/src directory there is no main issue. The problem arise when system libraries are header only. If we want to share in detail/win the files that avoid the inclusion of windows.h these files should be included always with the same API. If we don't share any file there is surely no issue. So I see two options: A- Don't share any file related to the windows.h replacement between the boost HEADER-ONLY libraries B- Share them, and use always the same API for all the HEADER-ONLY libraries. I don't agree in supporting both APIs on cygwin and let user to choose which one should be used. Only one needs to be implemented. --Vicente
On Thu, 06 Jan 2011 22:32:16 +0100, 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. So, boost libraries shouldn't use Windows interfaces when working under cygwin.
What's the experience of others?
My experiencie is that cygwin, since version 1.7, offers a good POSIX emulation and it should be treated like a UNIX OS. Inteprocess treats cygwin as a UNIX system and it offers both POSIX and XSI (system V) interprocess mechanisms. Best, Ion
At Sat, 08 Jan 2011 14:16:38 +0100, Ion Gaztañaga wrote:
On Thu, 06 Jan 2011 22:32:16 +0100, vicente.botet <vicente.botet@wanadoo.fr> wrote:
What's the experience of others?
My experiencie is that cygwin, since version 1.7, offers a good POSIX emulation and it should be treated like a UNIX OS.
Ditto -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Ion Gaztañaga wrote:
On Thu, 06 Jan 2011 22:32:16 +0100, 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. So, boost libraries shouldn't use Windows interfaces when working under cygwin.
What's the experience of others?
My experiencie is that cygwin, since version 1.7, offers a good POSIX emulation and it should be treated like a UNIX OS. Inteprocess treats cygwin as a UNIX system and it offers both POSIX and XSI (system V) interprocess mechanisms.
My expectation of using boost on cygwin was that I would be able to exercise code as if I were on a unix platform. I was surprised by system/filesystem use of windows api on this platform. Jeff
My expectation of using boost on cygwin was that I would be able to exercise code as if I were on a unix platform. I was surprised by system/filesystem use of windows api on this platform.
It was usefull, at least on cygwin 1.5: On cygwin 1.5, with boost 1.43.0 I use -DBOOST_POSIX_API -DBOOST_POSIX_PATH when I want cygwin binary I use -DBOOST_WINDOWS_API when I want windows binary (g++-3 -mno-cygwin) On cygwin 1.7, there is now a real cross-compiler i686-w64-mingw32-g++. What would be the "official" way to cross-compile to windows? Frédéric
participants (10)
-
Beman Dawes -
Boris Schaeling -
Dave Abrahams -
Frédéric Bron -
Ion Gaztañaga -
Jeff Flinn -
Jim Bell -
Stewart, Robert -
vicente.botet -
Vladimir Prus