Re: [boost] [type_traits] extension has_operator_xxx - cv qualifiers and references

Subject: Re: [boost] [type_traits] extension has_operator_xxx - cv qualifiers and references
From: Daniel Larimer (dlarimer_at_[hidden])
Date: 2011-02-10 17:20:06

On Feb 10, 2011, at 3:34 PM, Edward Diener wrote:

> On 2/10/2011 2:14 PM, Daniel Larimer wrote:
>> On 2/10/11 12:52 PM, "Frédéric Bron"<frederic.bron_at_[hidden]>  wrote:
>> 
>>>> as a possible user/tester of the library I would prefer if the library
>>>> package contains only the new files so we can decompress them directly on
>>>> the boost root system. If the name of the directory was specific this could
>>>> be even easier (e.g. why not movie temporary all your new files to a
>>>> specific directory "operators")
>>> 
>>> Can you tell me what you would like more precisely:
>>> - only the header files,
>>> - everything, including test files and documentation?
>>> 
>>> I could tar it so that if you extract it from a boost distribution you get:
>>> boost/type_traits/has_operator_xxx.hpp
>>> libs/type_traits/test/...
>>> libs/type_traits/doc/...
>>> 
>>> For the doc however the merge could be a problem...
>> 
>> When trying to work on a modularized boost, it would be very helpful if each
>> library was set up like so:
>> 
>>     type_traits/
>>         test/
>>         doc/
>>         ...
>>         src/
>>         build/
>>             *.jam
>>         boost/
>>             type_traits/hasoperator_xxx.hpp
>> 
>> Then use the .jam file to copy/symlink  libs/type_traits/boost/typetraits to
>> boost_1_45_0/boost/typetraits
>> 
>> Then developers could create a git,svn,cvs,tar.gz repository of just
>> 'type_traits' and put it in boost/libs and it would be very easy to manage
>> individual libraries without having to worry about the problems with
>> 'overlaying' two directory structures manually via .zip files.
>> 
>> It seems like such a change would be relatively small, yet ease the
>> transition to something like ryppl or Boost.CMake.
> 
> I do not think a jamfile should be copying anything to a hardcoded path outside of the directories in which the library resides. That is a real recipe for ticked off end-users.
> 

Boost.Context used something like this to overwrite boost/context/context.hpp with the proper version for the platform it was on.  

The only other option to avoid a copy would be to add  boost/libs/typetraits to the include path, but ultimately the headers need to be 'installed' someplace.  

I don't think it is any different than the jam file writing to the bin dir.  And having an unzip go wrong is much more likely to tick off a user than a 'well defined' bjam script.  Presumably a library 'owns' its directory in libs/MODULE and boost/MODULE and boost/MODULE.hpp  so as long as the library maintainer tells it to do the right thing that maintainer will not tick off end-users.

> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost