3 ms·

Better integrate may be, but not merge into one. Since super optimized build systems also increase complexity of their usage. So the idea is to have user friend

by shmerl 8y ago

Better integrate may be, but not merge into one. Since super optimized build systems also increase complexity of their usage. So the idea is to have user friendly front end, which produces complex input for very fast backend. Ninja view their build idea as "assembly like". While assembly surely allows you producing very fast results, it's not easy to use at all, if you are using it directly.

entelechy 8y ago
> Since super optimized build systems also increase complexity of their usage. That's not correct. Complexity arises from the inability of expressing what you want and lack of abstractions over platform details. Ninja for instance is to primitive to be productive and does not have any understanding of C++. Buildsystems like buck allow you to express things in a declarative manner eg.: cxx_library( name = 'foo', srcs = glob(['src/**/*.c']), exported_headers = glob(['*.h']) ) cxx_binary( name = 'app', srcs = ['main.c'], deps = [':foo', ':bar'] ) buck implements sophisticated (disk & network) caching, optimization and scheduling strategies to make things fast. Furthermore it will use services like watchman (if available) to precompute what things need building if you change some files for fast incremental builds. Lastly it will strip and sort symbols in your binary to make sure the hash of your binary is always the same for the same set of inputs. All this complexity is handled for you and all you need to do to run your executable is buck run :app
- shmerl 8y ago
  Ninja is by design low level, it doesn't need to know that about C++. That's the point of having a front end that would know about libraries and such. So not sure what you argument is about. It's like saying that assembly has no high end abstractions. Sure, it doesn't. It in itself is not an argument against splitting the build into several passes. That said, Buck looks like an interesting build system. In general, to have proper handling of librarires and etc. the language itself should support the notion of modules, like Rust does. Then you can implement sane tools (cargo). C++ is still crippled in this regard. Though there are some ideas how to improve it: https://medium.com/@dmitrygz/brief-article-on-c-modules-f58287a6c64 https://medium.com/@dmitrygz/brief-article-on-c-modules-f582...

by shmerl 8y ago

entelechy 8y ago

> Since super optimized build systems also increase complexity of their usage. That's not correct. Complexity arises from the inability of expressing what you want and lack of abstractions over platform details. Ninja for instance is to primitive to be productive and does not have any understanding of C++. Buildsystems like buck allow you to express things in a declarative manner eg.: cxx_library( name = 'foo', srcs = glob(['src/**/*.c']), exported_headers = glob(['*.h']) ) cxx_binary( name = 'app', srcs = ['main.c'], deps = [':foo', ':bar'] ) buck implements sophisticated (disk & network) caching, optimization and scheduling strategies to make things fast. Furthermore it will use services like watchman (if available) to precompute what things need building if you change some files for fast incremental builds. Lastly it will strip and sort symbols in your binary to make sure the hash of your binary is always the same for the same set of inputs. All this complexity is handled for you and all you need to do to run your executable is buck run :app

shmerl 8y ago
Ninja is by design low level, it doesn't need to know that about C++. That's the point of having a front end that would know about libraries and such. So not sure what you argument is about. It's like saying that assembly has no high end abstractions. Sure, it doesn't. It in itself is not an argument against splitting the build into several passes. That said, Buck looks like an interesting build system. In general, to have proper handling of librarires and etc. the language itself should support the notion of modules, like Rust does. Then you can implement sane tools (cargo). C++ is still crippled in this regard. Though there are some ideas how to improve it: https://medium.com/@dmitrygz/brief-article-on-c-modules-f58287a6c64 https://medium.com/@dmitrygz/brief-article-on-c-modules-f582...