Walter Landry wrote:
as to what you expect to happen. As you know, boost has a significant investment and momentum in designing and developing Boost.Build, we have an extensive test suite, and we even have fairly complete (if imperfect) documentation. Surely you recognize that it's unlikely anyone is going to look at a system whose "docs are a bit sketchy, and it still needs work for mere mortals to be able to use," determine that it really holds greater potential than everything we've developed and currently have planned, convince the other invested parties to change direction, etc?
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.
We (Boost.Build developers) are in fact very interested in a configure system. However, like Dave, I seem to miss the point of your post. Are you suggesting that we take your BuildSystem package and use it as basis for a configure solution for Boost.Build. Then, can you join us at Boost.Build mailing list (http://lists.boost.org/mailman/listinfo.cgi/boost-build), and give some more details about how your configure system works. Even rough outline is better than having to look at code that seem to lack any overview comments. Are you suggesting that we borrow some ideas from your solution? Then can you tell what are the most important ideas? Are you suggesting that we take your configure solution as-is, and apply to Boost? Then maybe you can write a small example? Looking at the configure.py you've linked, I don't see any checking for external libraries or headers, or something like that. - Volodya