
David Abrahams wrote:
The problem with adding another tool is that information can all be generated by the build system for dependent projects. Trying to replicate that capability externally and keep the two in synch would be a nightmare. That's why this should be done with the build tool. On the other hand, I'm not opposed to using a front-end atop Boost.Build for this purpose.
I agree that duplicating the data manually would be a maintenance nightmare. On the other hand, I don't think users of boost libraries should be required to know about bjam either. What I imagine is some 'database' (m4 file for autoconf, pkg-config file, whatever) that is *generated* by bjam as part of the build process. Unix developers are quite used to the idea: tools such as pkg-config work exactly like that. Appropriate files are generated during configuration / installation, and can be further tuned during the packaging, if necessary. Again, I'm thinking of platforms such as Fedora or Debian, which both have their own package management tools. If I want to develop software that is to use boost rpm or deb packages, I'd much appreciate some standardization of how to query the boost package(s) about required flags. If this isn't done as part of the boost project itself, packagers will do it, but probably not in a consistent way. Regards, Stefan