Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk