4 ms·

As your repo grows do you think you'll eventually need to implement some blaze-like tooling? In previous treads you mentioned compiling the entire repo only tak

As your repo grows do you think you'll eventually need to implement some blaze-like tooling? In previous treads you mentioned compiling the entire repo only takes a minute or two but I'm wondering if the reproducability guarantees would help an effort like this.

jart 5y ago
Author here. Believe it or not, I'm also the author of some of Blaze's coolest features, like its downloader, which reduced TensorFlow build flakes down from 10% to 0%. https://github.com/bazelbuild/bazel/commit/92887a08a55be96ec44e63f0ef0fd287cf49d0cb https://github.com/bazelbuild/bazel/commit/92887a08a55be96ec... The Cosmopolitan Makefile already has Blaze-like tooling. For example, it does strict dependency checking to verify the DEPS list for each static archive specifies all of its directly-reachable dependencies. https://github.com/jart/cosmopolitan/blob/b8f38cf55d84bac7d735ebbe58e1d9bf1956de39/tool/build/package.c#L58-L102 https://github.com/jart/cosmopolitan/blob/b8f38cf55d84bac7d7... See example build config here: https://github.com/jart/cosmopolitan/blob/b8f38cf55d84bac7d735ebbe58e1d9bf1956de39/tool/build/build.mk#L24-L59 https://github.com/jart/cosmopolitan/blob/b8f38cf55d84bac7d7... That was actually one of the first features I wrote for the Cosmopolitan codebase, because it has ~67 static archive .a files, and making sure those all get linked in the correct order and are acyclic would have been nearly impossible without such a tool. I'm sure in the future people will want a more Pythonic build syntax, since with GNU Make it's a bit easy to shoot oneself in the foot. The biggest issue contributors have had so far with the build is that we need to specify in the top-level Makefile a correctly topologically-ordered list of `include foo.mk` lines. Otherwise some pretty counterintuitive errors happen. But one grows used to it after a little pain and the repo feels like second nature. Ultimately, I just really didn't want to invent yet another build system. I'm pretty proud of the fact that (at least for now) I've managed to make GNU Make work so well for such a large repo. Google themselves actually used GNU Make for their codebase until around ~2005 so I'm hoping Cosmopolitan has got at least another decade of use in it.
- rockwotj 5y ago
  > I'm sure in the future people will want a more Pythonic build syntax > Ultimately, I just really didn't want to invent yet another build system. Is there a reason not to use Bazel initially or in the future when you want a Python syntax?
  - jart 5y ago
    No comment.

jart 5y ago

Author here. Believe it or not, I'm also the author of some of Blaze's coolest features, like its downloader, which reduced TensorFlow build flakes down from 10% to 0%. https://github.com/bazelbuild/bazel/commit/92887a08a55be96ec44e63f0ef0fd287cf49d0cb https://github.com/bazelbuild/bazel/commit/92887a08a55be96ec... The Cosmopolitan Makefile already has Blaze-like tooling. For example, it does strict dependency checking to verify the DEPS list for each static archive specifies all of its directly-reachable dependencies. https://github.com/jart/cosmopolitan/blob/b8f38cf55d84bac7d735ebbe58e1d9bf1956de39/tool/build/package.c#L58-L102 https://github.com/jart/cosmopolitan/blob/b8f38cf55d84bac7d7... See example build config here: https://github.com/jart/cosmopolitan/blob/b8f38cf55d84bac7d735ebbe58e1d9bf1956de39/tool/build/build.mk#L24-L59 https://github.com/jart/cosmopolitan/blob/b8f38cf55d84bac7d7... That was actually one of the first features I wrote for the Cosmopolitan codebase, because it has ~67 static archive .a files, and making sure those all get linked in the correct order and are acyclic would have been nearly impossible without such a tool. I'm sure in the future people will want a more Pythonic build syntax, since with GNU Make it's a bit easy to shoot oneself in the foot. The biggest issue contributors have had so far with the build is that we need to specify in the top-level Makefile a correctly topologically-ordered list of `include foo.mk` lines. Otherwise some pretty counterintuitive errors happen. But one grows used to it after a little pain and the repo feels like second nature. Ultimately, I just really didn't want to invent yet another build system. I'm pretty proud of the fact that (at least for now) I've managed to make GNU Make work so well for such a large repo. Google themselves actually used GNU Make for their codebase until around ~2005 so I'm hoping Cosmopolitan has got at least another decade of use in it.

rockwotj 5y ago
> I'm sure in the future people will want a more Pythonic build syntax > Ultimately, I just really didn't want to invent yet another build system. Is there a reason not to use Bazel initially or in the future when you want a Python syntax?
- jart 5y ago
  No comment.