Re: [boost] Summer of Code 2006

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 [1], 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 [1] 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 
not followable.

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