Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2005-03-22 16:08:13

"Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> writes:

> "David Abrahams" <dave_at_[hidden]> wrote in message
>> "Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> writes:
>>>> What inconvenience are you actually facing? Sorry, but I did get it yet.
>>> Let's say I want an apple sauce. Instead you giving me an apples (they
>>> may
>>> be good ones or not so much, since for sauce it doesn't really matter and
>>> why waste good apples on sauce) and saying that if I have powerful enough
>>> mixer (or whatever it called) I could get a sauce in just a second. And
>>> the
>>> reason you are telling me is that there are some people out there who
>>> may've
>>> want slightly less sugar. I believe it's not good enough: give me my
>>> sauce -
>>> I do not want spend time making one, I do not have an appropriate mixer
>>> and
>>> I do not have a space to store all these apples.
>> I understand what you're saying. On the other hand "install from
>> source" has become a standard practice in the open-source world. The
>> only thing that seems to make that argument less applicable than it
>> would otherwise be is that this software requires a fairly conformant
>> compiler. Right?
> Not only.
> 1. "install from source" practice is more *nix oriented.

Irrelevant to whether that argument is less applicable to wave.

> Cygwin for example doesn't require user to compile it's components

Cygwin is *nix. This is just the same as any other *nix system, where
precompiled binary packages are produced by the maintainers of the OS.
If I want some other arbitrary thing, like some special version of
GCC, I install from source just as I would on any *nix system. I've
done it many times.

Yes, many projects supply precompiled binaries, but if I want
something to work reliably in my environment I often find myself
building it. In fact, that's the standard way to get a Python
installation on *nix.

> 2. Wave at the moment does require conformant compiler while end ser may
> want to use it with different one

Yes, that's the one argument I was saying was applicable.

> 3. Boost is distributed as a set of libraries. The main point I am trying to
> make it we should separate tools into standalone packages and:
> a. Main delivery package includes only users docs plus location where
> prebuilt binaries are and where the source package is

you're suggesting that you get neither source nor tools with the "main
Boost package?" That doesn't sound right.

> b. We prebuilt tools for some set of OSs

Okay, well the wave tool isn't special in that regard; we have other
tools we're not prebuilding.

> c. Source package include reference docs and instruction how to build an
> executable from sources

Whoa; you intend to separate "users docs" from "reference docs?"
That's a major change.

> This practice could be applied to any tools including bjam and wave

And bcp, and...

This sounds like a pretty ambitious plan for restructuring what we
deliver. I do agree wholeheartedly that we need to reconsider the
structure of what we deliver, but I don't neccessarily think this is
the right plan. It doesn't seem to have precedent (at least not that
I've seen), and I'd want to see a much more detailed rationale before
buying into the details as you've described them.

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at