Re: New boost user

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-10-04 17:22:31

--- In boost_at_[hidden], Jeff Squyres <jsquyres_at_l...> wrote:
> 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.  

I'm not sure if the experience of Unix users is different... I tend 
to doubt it because I do d/l a lot of tarballs and gz files from Unix 
development sources that don't extract to subdirectories for me 
(experience is a 50/50 chance of an archive extracting to a subdir).  
Again, I don't really care if the convention is changed, though my 
preference is to not change simply because I prefer the flexibility 
afforded by not doing so.  The main point is that I simply don't 
agree that it's "anti-social" behavior one way or the other.

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

Again, you create the directory yourself before extracting.  I 
*never* extract directly into a root directory as 50% of the time 
you'll wind up with a mess ;).  By not naming the root directory in 
an archive, on the other hand, you leave me with the flexibility of 
naming my "root directory" for extraction anything I want.  I can use 
the version number name if that's the convention I want to follow, or 
I can leave the version number off if I don't plan to ever have 
multiple versions installed.  I think this gives you more control and 
I simply don't see it as a platform difference.
 
> 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.  
> :-)

If you don't know how to check, never assume what will cause you the 
most grief ;).  That's why I'm in the habit of creating the directory 
myself.  If I'm wrong it's trivial to move the files back a directory 
after they've been extracted.  It's the safest way to handle 
archives, IMHO.
 
> > > 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.  

I'm not sure that you'd want a list of test suits, etc.  *shrug*  I 
guess I don't find it to be an issue but can concede that others 
might.  I'll leave that one up to Beman and the others :).
 
> 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'"?

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 :).
 
> > > 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?

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

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.

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

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.

Bill Kempf