"Rene Rivera" <grafik.list@redshift-software.com> wrote
David Abrahams wrote:
Rune Sune <rune.sune@yahoo.com> writes:
--- David Abrahams <dave@boost-consulting.com> 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