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

Boost list run by bdawes at, gregod at, cpdaniel at, john at