Boost logo

Boost :

Subject: Re: [boost] Process discussions
From: Edward Diener (eldiener_at_[hidden])
Date: 2011-02-01 10:34:00


On 2/1/2011 5:02 AM, Paul A. Bristow wrote:
>> -----Original Message-----
>> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
>> On Behalf Of Edward Diener
>> Sent: Monday, January 31, 2011 6:35 PM
>> To: boost_at_[hidden]
>> Subject: Re: [boost] Process discussions
>>
>>>>> (And - aside - why it is not
>>>>>
>>>>> Trunk/
>>>>> Jamfile
>>>>> mylib/
>>>>> boost/
>>>>> libs/
>>>>>
>>>>> Why are there two 'extra' /mylib folders? Is this historical or
>>>>> is/was there some logic to it?)
>>>>
>>>> It's need in the header directory so that the include paths for
>>>> different
>>> libraries
>>>> don't clash.
>>>
>>> That seems lot of extra sub folders for something that a modest about
>>> of name control could avoid?
>>
>> My understanding is that it replicates the Boost structure. So one can
> refer to
>> one's header file paths as if one's top level directory is the main
> directory of a
>> Boost distribution. Then there is no need to change header file includes
> when
>> one's library is put inside a Boost distribution tree ( or some SVN branch
> like
>> 'trunk' which duplicates a Boost tree ).
>>
>> I think if you will look at the structure you will see this pretty easily.
>>
>>> (I note that there are some projects in sandbox that fail to follow
>>> this layout, so they are going to get into trouble :-( A template
>>> might help?)
>>
>> I agree with you. I honestly don't see why all possible libraries for
> Boost to be
>> reviewed are not in the sandbox using the recommended layout. It would
>> certainly make it much easier for others to use, test, review, and get
> updates to
>> such libraries when they occur. I think that this should be a Boost
> mandate: "if
>> you want to submit your library for a Boost review you need to get sandbox
>> access and put your library into it using the recommended directory
> structure." I
>> find that much easier than getting some library from some URL address on
> the
>> Internet or from the Boost vault, as a monolithic zip file, and unzipping
> and
>> hoping that the directory structure corresponds to something I can try
> without
>> wasting a great deal of time figuring out how to use said library.
>
> Your explanations are fine - and I strongly support enforcement of the
> 'Boost Standard File Layout.
>
> But IMO this shows:
>
> * Judging by a fair number of projects in sandbox, Boost has failed to get
> over to wannabe authors the requirement/desirability for this structure.

It is possible that quite a number of sandbox libraries are there from
before the time when the desired file layout was documented.

>
> * Boost search and/indexing is ineffective. Using the Boost page clicking
> on "Search Boost" doesn't produce any helpful links.
> (nor does refining the search to only www.boost.org). FAQ doesn't help. The
> index is tiny for such a massive site, and is no help for this question.
>
> * Eventually one might find http://www.boost.org/community/sandbox.html .
>
> * This tells you *what* you need to know, but not *why* it is like that.
>
> * Telling *why* often gives a big push to compliance.

Agreed.

If no one enforces the desired directory structure or, better yet, if no
one enforces the idea that libraries up for review need to be in the
sandbox using that directory structure, then people will not do it. I
especially think the latter would be most effective.

At one time there was the suggestion, I believe, that the Boost Vault's
projects should be folded into the sandbox and then done away with, but
nothing was ever done in that direction.

Part of a problem with Boost is that there does not seem to be any
document on who is empowered to get things done in various areas
regarding Boost decisions. We all generally know who are the leaders
among the developers of Boost, but if you were to ask Boost developers
who is empowered to make changes in various areas I have the feeling
that few would know, and I certainly do not.


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