Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-10-05 15:49:12

--- In boost_at_[hidden], Jeff Squyres <jsquyres_at_l...> wrote:
> On Wed, 4 Oct 2000, William Kempf wrote:

I want to be very careful here. My first post on this thread was
made because you made a couple of small comments that I didn't agree
with, mostly because of my platform bias (which is important to
voice), and because I thought I could help you to understand why
things are the way they are right now. I was not trying to suggest
that they remain that way, nor to suggest that I have any control of
the decisions made (I'm mostly a user, like you, though I'm being
pushy about the thread library).

So... I feel like I should respond this one more time to address a
couple things you said here, but since I don't make the decisions
I'll probably bow out of this particular thread after that. I don't
want to cause too much static on the list over a topic as difficult
as this one that needs to be decided on by a core set of individuals
who may or may not care about what we have to say here (at least to
the point where things degenerate into pointless arguments).
> Is it not uncommon for README kinds of files to include a listing
of the
> top-level directories and generally what is in them. Doesn't need
to be a
> complete roadmap.

A road map of directories would be useful, *IF* the directories were
better structured. Not to knock the efforts made already, but I
think this discussion has already pointed out that mixing test code
in with implementation code in the same directory leads to confusion
on the user's part. So, I think a little restructuring of
directories is needed first. The ironic thing is, if you name the
directories well then after the restructuring there's not much need
for a "road map" in a README file.
> But regardless -- I'm not suggesting that this is strictly
> What I'm suggesting is necessary is some kind of usage

We've talked about this one, so there's not any confusion by what you
mean here any more. However, I still don't like the term "usage
documentation". Usage implies how one uses the library, which is
documented (as much as it need be) in the library documentation
files. No, what's needed is "build documentation" (which for some
libraries is nothing more than "just includedthe header file").

I'm going to say it again, just so those that aren't familiar with
Boost history understand why this hasn't already been done, even
though I agree with you that it's time to start doing it. Until the
addition of Regex and BGL the libraries were small and self contained
and required very little effort to use in any manner that the
developer deemed appropriate for his needs. So there wasn't any
impetus for such documentation.

Things have changed. So I agree, I think we need more documentation
on this topic.

> I guess is comes down to: who is the target audience for boost?

Tricky question, but irrelevant. Whether Boost users are the target
audience or Boost is simply an attempt to develop new concepts for
C++ (it's really both, obviously, the question is where the emphasis
is) the target audience is growing very fast, and includes users that
aren't as familiar with a lot of the concepts required. So
regardless, it's time to start making things more user friendly.

> I mention
> this becuase there are a lot of fine programmers out there who care
> about compilation processes, and don't give a hoot about intracate
> details.

Very true.
> > > the stuff under libs is actually implementation and test
> > code?
> > > Which is which?
> >
> > Mostly test, a little implementation. Right now you kinda have to
> > figure out which is which on your own (really not too difficult
at the
> > moment, though it will get *MUCH* worse as we grow). How you use
> Agreed; I could more or less figure it out when I looked at it, but
> get more difficult.

*Much* more difficult.
> But it might make sense to logically separate the implementation and
> testing code in separate directories. In some ways, this even
> sanity checks on the developers within their own code.

Very much agreed.
> > code that requires implementation is kinda up to you. It's kinda
> > to decide how to do this in a platform neutral way right now...
> > they are working on this. Just a for instance on the problems
> This is fine -- if it hasn't been done for a specific reason, then
> document it. i.e., this is a good statement to put in a README

Agreed. While Boost was small this was just something that everyone
knew. Now it's important that it's documented for new users. Along
this line, I really agree with another recent poster (don't remember
who it was)... it's time to start another Boost list for users of the
libraries. Users are likely to be bored to tears by the development
discussions we normally have on here, while their usage questions are
going to very quickly become difficult to deal with in this list.
What do you say Beman? Start a new eGroup?
> > involved... do you create a static or dynamic library, how do you
> > configure the compiler/et. al. to create them in a platform
> > way, etc. I know that other libraries have done this in the
past, but
> > most of them favor *nix and ignore other platforms, which Boost
> > shouldn't do, or they jump through tremendous hoops to accomadate
> > other platforms resulting in build processes that require
> > efforts to get working on some platforms. That's why you find a
> > of GNU packages being distributed only as binary archives for
> > and Mac, with some *nix person doing a cross-compile to create
> > I don't think this is the right answer for Boost, though it could
> > made to work.
> Also agreed. I don't have any opinion on this; I'll let others

I don't think they'll comment (much any way), but there are people
working on this.

> > > [sample makefile foo snipped]
> > >
> > > Heck, I would even willing to write write a and
> > necessary
> > >'s to install all the .hpp files, and make a sample
> > Makefile
> > > like the one shown above. Much of the logic to get the
> > flags can
> > > be stolen from libs/, for example, and config.hpp
> > already does
> > > most of the rest.
> >
> > Great for *nix, not so great for the rest of us, though I do
> > understand your frustration. Maybe temporarily it might make
> > for someone on each platform (roughly) to provide a means to
> > what's needed for native tools? I don't know. The right answer
> > something that's going to take a while and we've recently grown
to the
> > point where it's going to be hard to wait.
> That might not be bad. As I mentioned, I'd volunteer to help with
> Unix side.

I'd also volunteer for the Windows side, which covers 3 sides of
the "big three". Problem is, this isn't very maintainable, so trying
to do this could lead us down a slippery slope that could get in the
way of the efforts of trying to come up with a real answer to this
problem. I think that if efforts were made to do this they should be
splinter efforts. The d/l should be on seperate hosts under the
control of individuals. This would remove all possibility of any
impact to the progress to Boost itself. Boost could provide links to
the sites maintenaining such efforts.
> > > > [more license rant snipped]
> > > >
> > > All this file gives is the licence requirements for a submitted
> > library.
> > > It does not spell out what the license is for boost itself.
> > to the
> > > point: a submitted library != boost. Hence, what is spelled
out on
> > that
> > > page is not the license for boost.
> >
> > Boost is a collection of libraries. Each library has it's own
> > liscensing. The Boost collection itself does not have a
liscence, but
> > instead your governed by the liscense of the individual
> > At least this is my understanding of how things work.
> But each library does *not* have a license. Correct me if I'm
wrong, but
> only GGCL has an explicitly stated license. There are little
blurbs in
> the tops of each header and source file in boost -- is this what
you are
> referring to? Are those really sufficient? My only criteria is
that the
> GGCL LICENSE file is much more detailed and much more specific than
any of
> those other blurbs. Indeed, most other licenses have much more
> and put little blurbs in the tops of header/source files that
mainly refer
> to the main [much more verbose] license.
> Again, I'm no legal expert, so if I'm wrong, great -- everything's
> covered. I was just under the impression that the blurbs in the
> files were not enough.

I'm not a lawyer, so someone will correct me if I'm wrong. I assume
that the libraries with out a specific liscense are in the public

Bill Kempf

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