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:
>>> 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:
>> Then use the .jam file to copy/symlink libs/type_traits/boost/typetraits to
>> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk