Re: [boost] Re: New boost user

From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2000-10-05 13:44:56

On Wed, 4 Oct 2000, William Kempf wrote:

> > [moot directory discussion snipped]
>
> Uhmm... a GUI or Windowsy person isn't going to be any different ;).  
> I just don't think we need a complete road map of all of the files.  
> Maintaining such a map would be problematic I think.  Just MHO there,
> and I'm not the one to make any decisions here :).

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.

But regardless -- I'm not suggesting that this is strictly necessary.  
What I'm suggesting is necessary is some kind of usage documentation.
If that takes the form of a top-level directory map, fine.  If it is an
example Makefile, fine.  Just something that can point a user in the Right
direction.

I guess is comes down to: who is the target audience for boost?  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.

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

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.

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

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

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

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

{+} Jeff Squyres
{+} squyres_at_[hidden]
{+} Perpetual Obsessive Notre Dame Student Craving Utter Madness
{+} "I came to ND for 4 years and ended up staying for a decade"