Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk