Boost logo

Boost :

Subject: Re: [boost] [type_traits] extension has_operator_xxx - cv qualifiers and references
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-02-10 15:34:13

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 list run by bdawes at, gregod at, cpdaniel at, john at