Walter Landry wrote:
David Abrahams <dave@boost-consulting.com> 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