On 6/21/17 6:47 AM, Chris Glover via Boost wrote:
On Wed, 21 Jun 2017 at 04:01 Thomas Heller via Boost
wrote: Interesting that you bring this up ... If you are so much in favor of a declarative build system, we already have multiple. For example plain old make or Boost.Build. With that being said, wouldn't it be more viable to improve Boost.Build with: - Better Documentation - More examples
Boost build has been hampered by a number of design decisions which have never been revisited. a) It is "too smart". It tries to infer the toolset by looking around the file system. If one has more than one compiler set there is really know way to know which one is going to pick. So then one is forced to go into the workings of boost build to figure out how to over ride this behavior. b) It is driven by "side effects" that is the environment. It searches the local file system starting from the current directory and up the tree for a "special" Jamroot file. So if you move your project to another directory, there is no guarantee that it will work the same. This was seen by the original designers as a feature - it's smart enough to know what you really want. c) It has non-obvious dependencies on other files which one generally doesn't know about: user-config.jam (in the users home directory), project-config.jam (hmmm I'm not sure where this supposed to be), etc. All these are fruit of the idea that - we, the developers of bjam can figure out what you need so the build will be really simple. To fix bjam this idea has to be set aside. All of the linkages to other stuff in the file system should be replaced by either data in the jamfile or if not in the jamfile better yet runtime switches so the command syntax would look like b3 toolset="asfasfa" variant="12321" etc. Which would respond with: build failed, errors found: toolset "asdfasdf" not found variant must be either "debug" or "release" no jamroot specified in either jamfile or command line ... So now the user is sent to look for the specific piece of information he has to add. users who couldn't put stuff in the Jamfile who are tired of putting the stuff on the command line would address this as we always to - a oneline local script - Of course this would be coupled with the manual which would describe this stuff. Actually, the text for this stuff is already in boost build docs. It's just that no one knows what part he needs to read to get it right. So compiling this document and code reorganization to support the above would have to go hand in hand. Bjam is much, much better than is generally appreciated. Its' just that the designers were/are too clever and presume we are also. Robert Ramey