Re: [boost] [gsoc] Boost.Process done

Subject: Re: [boost] [gsoc] Boost.Process done
From: Boris Schaeling (boris_at_[hidden])
Date: 2010-09-02 16:27:04

On Thu, 02 Sep 2010 00:36:33 +0200, Ilya Sokolov <ilyasokol_at_[hidden]>  
wrote:

> On 02.09.2010 2:09, Boris Schaeling wrote:
>> On Wed, 01 Sep 2010 23:51:07 +0200, Ilya Sokolov <ilyasokol_at_[hidden]>
>> wrote:
>>
>>>> I quote then the paragraph starting with "The benefits of using
>>>> components from other libraries...". ;)
>>>>
>>>> Anyway, while it all sounds good in theory how many developers are out
>>>> there trying to use single Boost libraries without installing the
>>>> others?
>>>
>>> Actually, I wasn't thinking about such developers, but about  
>>> compilation
>>> time (lexical cast and algo.str), portability and stability
>>> (filesystem).
>>>
>>>> It sounds like a bit too much effort reinventing what has been
>>>> implemented in other Boost libraries for what I expect is a relatively
>>>> small group of developers?
>>>
>>> The dependencies I object to are easy to avoid.
>>
>> Regarding boost::lexical_cast: There is to_string() in Boost.Uuid in
>> 1.44 but not in 1.43. Or what were you thinking of?
>
> I was thinking about sprintf or ostringstream. If you add async_pipe,
> there will be no need for Boost.Uuid

I don't want to give up named_pipe entirely as we don't know if someone  
has a need for it. I see then three possibilities:

1) Macro to exclude named_pipe
2) Move named_pipe to another header file
3) Move all behavior types to a subfolder called behavior and create a  
header file for each type

Any preference? Or is it possible to detect whether a library is  
available? Are there somewhere (eg. in Boost.Config) macros defined like  
BOOST_LIBRARY_UUID? If it's not defined Boost.Process would know it  
shouldn't try to include boost/uuid.hpp.

Boris