Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-10-04 16:53:12


--- In boost_at_[hidden], Phil Edwards <pedwards_at_d...> wrote:
>
> On Wed, Oct 04, 2000 at 02:22:46PM -0600, Dan Nuffer wrote:
> > Jeff Squyres wrote:
> > >
> > > --> RECOMENDATION: Have boost_all.zip extract to its own
subdirectory.
> > [snip]
> > > --> RECOMENDATION: Add some kind of version number into boost.
> [more snippage]
> >
> > 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.
>
> If both a .zip and a .tar.gz are to be distributed, then they should
> probably behave the same. Even if we stick with just the .zip for
> now, I would expect some kind of directory to be created by default.
> What's more, the unzipping programs I'm familiar with have settings
to
> ignore the subdirectory pathnames and extract into the current
directory
> upon user request, but the reverse is not true.

This option puts *ALL* the files into the directory extracted to,
which simply won't work. I can live with the zip containing a "root
directory name", I just don't agree that it's "anti-social behavior"
for an archive not to do this.

> The .# files are indeed accidental CVS cruft; apparently the zip
file was
> created by someone with a not-quite-clean working directory. They
don't
> exist in the repository, nor in fresh checkouts.
>
> As far as building the library, Makefiles, and stored version
numbers... yes,
> those are probably going to be needed at some point. When the
library is
> "only" a collection of headers, those requirements are somewhat
arbitrary,
> but if we're having to actually build source files, then those
become needed.

This is true now, with the addition of Regex.
 
> Utilities like autoconf, automake, and libtool are really helpful in
> this regard. (Using auto* is not difficult. In my experience, only
> six people in the world understand libtool; two have entered distant
> monasteries under a vow of silence, three are in various padded
asylums,
> and Alexandre Oliva is subscribed to this list.)

These tools are not portable. They don't exist on Windows with out
extensive d/l of GNU tools, and even after this confusing d/l and
installation of GNU tools you'll be lucky to get them to work
reliably there. That's just one platform with problems... I'm sure
there's others.

Bill Kempf


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