Thanks for bringing that up, I agree that the example is quite trivial, though I think it's at least a fair comparison when it comes to general complexity of tw

Thanks for bringing that up, I agree that the example is quite trivial, though I think it's at least a fair comparison when it comes to general complexity of two simple projects. Regarding find_package; it does sound similar to bake's discovery. There is a not insignificant difference though between how both work in practice. Without going into too much depth, CMake attempts to find a package by looking at (a potentially large number of) system paths. It attempts to adhere as well as possible to the conventions of that platform. On the other hand, bake recursively searches for projects from where it is being invoked, in addition to looking in a "bake environment". The latter is a self-contained, fixed-format directory structure that contains all projects built with bake. A bake environment is by default stored in a user's $HOME folder, but can be configured to (for example) /opt. Bake environments can be easily moved to different directories and even machines. There is nothing inherently right or wrong with either approach, but they are certainly different. Bake's approach was designed to accommodate a scenario where a developer is working on a large number of (potentially shared) projects at the same time, and for that it works really well. Bake has been used for well over 4 years (in various iterations) in big and small organizations. It held up pretty well for large-scale projects, though I should mention that, as with any tool, it can be misused. Big organizations in particular will have to establish conventions and guidelines around using bake, just as they would have to do with any other approach.