|
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
> news:u7jjz66s2.fsf_at_boost-consulting.com...
>> "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 www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk