5 ms·

Blaze is the one thing I miss the most from Google. However Blaze is very heavy for most small open source projects as the article says so the startup cost is t

by zaphar 11y ago

Blaze is the one thing I miss the most from Google. However Blaze is very heavy for most small open source projects as the article says so the startup cost is too high. I think there is probably room for a blaze-lite that relaxes a few of the restrictions blaze requires and is written in an easier to deploy language. Go perhaps? The build rule language and the correct dependency specification and tracking are the most important pieces to have in my opinion. You could drop the expectation that all the dependencies including the compiler toolchain are in the source repo without losing too much.

shoover 11y ago
waf [1] is very close to what you describe. It's all Python. It's built so you can include one Python file in your source tree and install nothing but Python. A relatively small core handles dependency tracking and shuffling flags from the user to tasks. I can't believe how fast it is, considering it is reading the files and computing hashes. While user scripts have access to all of Python, you can limit yourself and write rules in a high level build rule style that's only slightly more Pythonic than Bazel, et al. Basically it's bld.program(source=['main.c'], use=['foo']) or bld(features='c cprogram', source=['main.c'], use=['foo']) instead of cc_binary(srcs=['main.c'], deps=[':foo']). Adding rules can be done in various ways, including genrule-style shell commands, registering a task class by file extension, and a very flexible system of registering methods to hook into the "features" attribute. With surprisingly little work, you can layer your own build language on top of the core modules. Demos are provided that parse makefiles or generate rules by searching the source directory with no user script [2]. Relative to the OP's concerns, a configure step is required and can search the system, call pkg-config, write config.h, etc. Arbitrary command line options can be added by shared tools and user scripts. Install, dist, and distclean are all there. [1] - https://waf.io/ https://waf.io/ [2] - https://github.com/waf-project/waf/tree/master/build_system_kit https://github.com/waf-project/waf/tree/master/build_system_...

by zaphar 11y ago

shoover 11y ago

waf [1] is very close to what you describe. It's all Python. It's built so you can include one Python file in your source tree and install nothing but Python. A relatively small core handles dependency tracking and shuffling flags from the user to tasks. I can't believe how fast it is, considering it is reading the files and computing hashes. While user scripts have access to all of Python, you can limit yourself and write rules in a high level build rule style that's only slightly more Pythonic than Bazel, et al. Basically it's bld.program(source=['main.c'], use=['foo']) or bld(features='c cprogram', source=['main.c'], use=['foo']) instead of cc_binary(srcs=['main.c'], deps=[':foo']). Adding rules can be done in various ways, including genrule-style shell commands, registering a task class by file extension, and a very flexible system of registering methods to hook into the "features" attribute. With surprisingly little work, you can layer your own build language on top of the core modules. Demos are provided that parse makefiles or generate rules by searching the source directory with no user script [2]. Relative to the OP's concerns, a configure step is required and can search the system, call pkg-config, write config.h, etc. Arbitrary command line options can be added by shared tools and user scripts. Install, dist, and distclean are all there. [1] - https://waf.io/ https://waf.io/ [2] - https://github.com/waf-project/waf/tree/master/build_system_kit https://github.com/waf-project/waf/tree/master/build_system_...