Re: [boost] cygwin API: posix or windows

Subject: Re: [boost] cygwin API: posix or windows
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2011-01-08 08:09:28

----- Original Message ----- 
From: "Boris Schaeling" <boris_at_[hidden]>
To: <boost_at_[hidden]>
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_at_[hidden]> 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