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