Re: New boost user

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 
necessary.  
> What I'm suggesting is necessary is some kind of usage 
documentation.

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 
little
> about compilation processes, and don't give a hoot about intracate 
build
> details.

Very true.
 
> > > ...so 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 
the
> 
> Agreed; I could more or less figure it out when I looked at it, but 
will
> 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 
enforces
> sanity checks on the developers within their own code.

Very much agreed.
 
> > code that requires implementation is kinda up to you.  It's kinda 
hard
> > to decide how to do this in a platform neutral way right now...  
but
> > 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 
file.

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 
neutral
> > 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 
tremendous
> > efforts to get working on some platforms.  That's why you find a 
lot
> > of GNU packages being distributed only as binary archives for 
Windows
> > and Mac, with some *nix person doing a cross-compile to create 
them.  
> > I don't think this is the right answer for Boost, though it could 
be
> > made to work.
> 
> Also agreed.  I don't have any opinion on this; I'll let others 
comment.

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 configure.in and 
the 
> > necessary
> > > Makefile.am's to install all the .hpp files, and make a sample 
> > Makefile
> > > like the one shown above.  Much of the logic to get the 
compiler 
> > flags can
> > > be stolen from libs/regrtest.py, 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 
sense
> > for someone on each platform (roughly) to provide a means to 
create
> > what's needed for native tools?  I don't know.  The right answer 
is
> > 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 
the
> 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.  
More 
> > 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 
libraries.  
> > 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 
verbage,
> 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 
boost
> 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 
domain.

Bill Kempf