From: Rene Rivera (grafik.list_at_[hidden])
Date: 2006-04-20 23:15:07
Walter Landry wrote:
> David Abrahams <dave_at_[hidden]> wrote:
>> I'm always very curious when you make this reference (you've mentioned
>> this before, right? Sounds familiar)
> This is the first time I mentioned this system. In the past I just
> wanted a configuration system of any kind. There is sort of one
> already , but now there seems to be talk of implementing something
> more ambitious. You can spend an eternity working on this problem. I
> would prefer if Boost got out of the business of build systems, and
> instead focused on just writing great libraries.
As I allude to in the intro to the boost.build section of the SoC wiki
page, I personally think writing great libraries isn't just about
writing the code for those libraries. The tools one uses, and the
documentation one creates is much of the time more important. If just
for the plain reason that having good tools allows one to concentrate
more on the libraries. As a mentor for Computer Science students I would
think that the development process is the key point of SoC. The
resulting code is just an excuse to get students acclimated to working
in Open Source development process. (Yes I'm intentionally framing this
only within the SoC.)
Which  are you referring to?
> I am not suggesting getting rid of Boost.Build entirely. BuildSystem
> would be used for configuration, and Boost.Build could still be used
> for building. I use BuildSystem with SCons. Petsc uses it with make.
That's fine... But it's hard to respond to your suggestion given that I
wasn't able to figure out where and what this "BuildSystem" does. Trully
I looked around in the code references you pointed out and it is just
As for using it to "solve" the SoC project I would be open to a Python
solution. Just as long as it integrates transparently with the
Boost.Build structure. Specifically that we can create configured output
files as targets within BBv2 for whatever the build variant
specifications is requested within the various builds. More likely I
would expect the student to have to heavily modify any outside source
and of course heavily document that code.
PS. Just because someone else has already done it doesn't mean it isn't
worthwhile to redo. After all that "it's already done we'll just hack it
a bit" attitude is why Autoconf is still in use.
-- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk