Re: [boost] Re: New boost user

From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2000-10-04 16:15:05

On Wed, 4 Oct 2000, William Kempf wrote:

> > 1. [snipped--extract into subdir rant]
> 
> Actually, I've never seen a trend one way or another to indicate
> "anti-social behavior".  In fact, I personally hate zip files that
> create a subdirectory.  I *always* create the directory myself, unzip
> there, and in the (about 50%) cases where it created another
> subdirectory underneath mine I copy the stuff back.

I think Dan said it best in his followup message:

        I think distributing a .zip file that doesn't extract to a
        subdirectory is a good idea also, that is what Windows users
        expect from .zip files.

I am definitely showing my Unix bias here -- I would like everything
extracted into a single subdirectory.  

One more reason to extract into a separate subdirectory -- prevent
file/directory name conflicts.  It's analogous to why you use C++
namespaces.  :-)  Even though boost_all.zip extracts itself [mostly] into
various subdirectories, who is to say that a user is not already using
those subdirectory and file names?  "index.htm" and "libs" are prime
examples of this.  However, you can be reasonable certain that no one will
be using the name "boost-x.y.z".

Sidenote: I typically check tarballs to see if they will extract into a
separate subdirectory (tar tvf foo.tar), but I didn't know offhand how to
do that with a zip file.  Hence, I just assumed that it would...  Oops.  
:-)

> > 4. [snipped-no README rant]
> 
> It does give such information.  The very first link is to "libraries"  
> which details this info.

No, this gives the documentation for the various classes.  It lists 
the files involved with the classes and whatnot, but it doesn't list the
test suites, what's in the "more" directory, etc.  

Command line unixy people tend to look at what was extracted, and wonder
"what's in 'more'?", and "what's in 'people'?", and "what's the difference
between 'libs' and 'boost'"?

> > What I'm getting at is that there is no guidence on how to use the
> > libraries at all.
> 
> The library documentation discusses this.  What's really lacking is
> documentation on how to build those libraries that require some
> building.  Until we've got a portable way of doing this, it seems like
> something very difficult to do ;).

That's what I meant.  If I wasn't clear on that point, that's what I was
trying to say -- there's no information on how to *use* the libraries.

> > Granted, a user can put the "boost" subdirectory in some central 
> include
> > directory somewhere, but what about all the .cpp files (i.e., most 
> of the
> > stuff under libs)?
> 
> For the most part that's all test harness code.  It has little to do
> with useage of the libraries.  The one exception that I'm aware of is
> the Regex stuff... which is documented in a README within that
> directory.  Not necessarily intuitive, I agree, but it is documented.

The timer stuff was actually the first thing that I looked at, and it
appears to be split into boost/timer.hpp and libs/timer/*.cpp.

...so the stuff under libs is actually implementation and test code?  
Which is which?

> > some boost library.  Heck, even a minimal Makefile with "INSERT YOUR
> > COMPILER HERE" and "INSERT YOUR CXXFLAGS HERE" would be great (I 
> don't
> > know what to say for Windows users -- I'm not a Windows developer)
> 
> It's simply not that simple, even on *nix systems ;).  That's why *nix
> relies so heavily on autoconf et. al.

Agreed.  My point was that *some* kind of guidence, even a minimal
makefile with something like:

-----
CC		= INSERT_YOUR_C++_COMPILER_HERE
BOOST_DIR	= /home/directory/of/boost
INCFLAGS	= -I$(BOOST_DIR)/boost \
                  -I$(BOOST_DIR)/boost/detail \
                  -I$(BOOST_DIR)/boost/graph \
                  -I$(BOOST_DIR)/boost/pending \
                  -I$(BOOST_DIR)/boost/re_detail
CXXFLAGS	= INSERT_NECESSARY_CXXFLAGS_HERE \
                  $(INCFLAGS)
CXXLDFLAGS	= INSERT_NECESSART_CXXLDFLAGS_HERE
# ...and any other -L / -l flags, or whatever
-----

I know that this is not standardized.  It is just a bare-bones idea that
I'm suggesting.

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.

> > 6. [snipped--license rant]
> 
> Documented in boost/more/lib_guide.htm#License.  Each submission may
> have it's own liscensing (that's why you find a LICENSE file in
> libs/graph) but said licensing must abide by Boost restrictions, which
> includes the ability to be used in closed-source proprietary
> commercial code.

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.

{+} 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"