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 20:39:52

On Feb 10, 2011, at 5:41 PM, Edward Diener wrote:

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

I think you misunderstood what I was saying.  I was not suggesting that it should install anyplace outside of the boost_1_4x_0 directory where you are building.  You could have multiple boost versions/sandboxes.  I am simply suggesting that to "add an unofficial library" to your sandbox you should only have to unzip (or git clone) one folder in libs and not have to manually place files in multiple locations.

boost_1_44_0
        ...

boost_1_45_0/
        libs/
                context/  (context git repository)
                        boost/
                                context/
                                        context.hpp
                        src
                        examples
                        ... 
                        build
                                .jam (creates symlink or copies ../boost/context  to ../../../boost/context )
        boost/
                context -> ../libs/context

Currently there is no way (that I know of) to have a git repository checkout 'partial trees' such that you can overlay multiple git repositories (one for context, one for atomic, one for some other library) inside the same sandbox.  

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