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: Edward Diener (eldiener_at_[hidden])
Date: 2011-02-10 17:41:05

On 2/10/2011 5:20 PM, Daniel Larimer wrote:
>
> 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.

If it is writing to some place outside of its tree, it is wrong. How can 
a library know where the user is running its jam files from ? Unless of 
course the library spells out a restriction that it must be installed on 
top of some Boost distribution to work.

>
> 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 have put a query in the build NG as to why the Boost Build system 
places the includes for a Boost distribution before the includes of a 
sandbox library itself. This to me is clearly wrong.

>
> 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.

The bin directory is within the directory structure of a Boost 
distribution or sandbox library. If I am testing a sandbox library from 
its own directory how can it know where to put files outside its own 
directory structure ? It does not even know what Boost distributions I 
have on my system.