|
Boost : |
From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2006-04-24 14:10:51
"Rene Rivera" <grafik.list_at_[hidden]> wrote
> David Abrahams wrote:
> > Rune Sune <rune.sune_at_[hidden]> writes:
> >> --- David Abrahams <dave_at_[hidden]> wrote:
>
> >> That is, it is unnecessary high from the end-users viewpoint. If the
> >> newbie only had the usual interface towards the development project,
> >> i.e. make- or dsp-files, he could focus on his key problems instead
> >> of having to grasp all of BB.
> >
> > The user doesn't have to grasp all of BB. We just need improved
> > getting started directions, which I am writing. Only a very small
> > amount of grasping is required.
> >
> > If you want make- or dsp- files (note that dsp files are platform
> > *and* compiler-specific), figure out a way to generate them from
> > within Boost.Build, and we'll include them.
>
> Which is what the second SoC Boost.Build project I'm willing to mentor
> is about.
I am sorry, although I can probably be qualified as a Windows developer, I
don't understand what dsp files have to do with building Boost...
I can see two equaly acceptable (from the user's point of view) options of
building Boost:
1) user gets ready to use binaries for his platform as a part of some sort
of InstallShield-like setup process;
2) user gets some script file, that he runs with some parameters, and gets
binaries as a result. As a (less convenient) altenative, this can be a set
of commands to run, but the step-by-step instructions what to do (and what
to expect, and what can go wrong) should be located at the same place, and
no previous knowledge should be assumed (other than general OS knowledge).
So, where do dsp files belong here?
Regards,
Arkadiy
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk