Re: [boost] Lighweight header-only version of Boost.Filesystem?

Subject: Re: [boost] Lighweight header-only version of Boost.Filesystem?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2011-08-24 06:53:44

Le 24/08/11 04:41, Dave Abrahams a écrit :
> on Sat Aug 20 2011, "Vicente J. Botet Escriba"<vicente.botet-AT-wanadoo.fr>  wrote:
>
>> Le 20/08/11 18:07, TONGARI a écrit :
>>> 2011/8/20 Beman Dawes<bdawes_at_[hidden]>
>>>
>>>> On Wed, Aug 17, 2011 at 8:56 AM, Mathias Gaunard<
>>>> mathias.gaunard_at_[hidden]>   wrote:
>>>>
>>>>> I.....>Therefore, I would really like it if there was a lightweight
>>>>> header-only version of Boost.Filesystem.
>>>>> I don't need the full extent of features; I just need to have the ability
>>>>> to do the following portably:
>>>>>    - read all files of a directory
>>>>>    - create directories
>>>>>    - remove files and directories
>>>>>    - rename files and directories
>>>>>
>>>>> The first point being the most important.
>>>>>
>>>> A header-only version would be a nice feature to offer.
>>>>
>>>> But it may be more time consuming to implement than it would appear.
>>>> Vicente
>>>> Botet tried to do the same with Boost.System, and ran into problems.
>> I reached to get a header-only version of Boost.System. The main
>> issues raised by Beman were that we need to have a consensus on how
>> all the header only libraries behave under cygwin respect to the WIN
>> not WIN interface. IMO when we use cygwin we shouldn't use the Windows
>> API, Bemans prefered to use it as it was available.
> What does "under cygwin" mean, exactly?
>
> It seems to me like a no-brainer that when the target OS is Cygwin, we
> should use the cygwin POSIX APIs, and when the target OS is Windows (as
> it might be when using cygwin GCC with the -mno-cygwin flag), we should
> use the Windows APIs.  Is there anything more to this decision than
> that?
>
Hi,

thanks for the precisions. I guess you are right.

I don't remember exactly the source of the problem, but when I tried to 
use Boost.Chrono and Boost.System inlined both libraries where not using 
the same interface. I will need to restore the context and see what was 
going wrong (Or find in this ML)

Best,
Vicente