3 ms·

1) bazel can be built with a self contained bundled paired down jvm, and possibly an executable using GraalVM but I don’t know anyone who tried that yet. 2) ba

1) bazel can be built with a self contained bundled paired down jvm, and possibly an executable using GraalVM but I don’t know anyone who tried that yet. 2) bazel can do offline compiles, and is actually built to run in sandboxes 3) bazel can act as a build system only and delegate to externa package managers Look at rules_nodejs for example and the managed_directories + yarn_install/npm_install rule 4) depend on already installed stuff. Toolchains already provide a way to do this, and the android_sdk_repository rule literally requires preinstallation. Seems to me your making a lot of claims about bazel without having used it.

adev_ 7y ago
> Seems to me your making a lot of claims about bazel without having used it I lost literally weeks of my life to make Bazel work in external build systems for tensorflow and others. And I am apparently not the only one : https://archive.fosdem.org/2018/schedule/event/how_to_make_package_managers_cry/ https://archive.fosdem.org/2018/schedule/event/how_to_make_p... Then I don't allow you to tell me "not having used it". All the answers you gave are "fixes" that have been made after the community complained. Fixes that were sometimes not even documented.
- cromwellian 7y ago
  Bazel is based on Blaze, which is Google's internal mono repo build system. But Angular, Kubernetes, Tensorflow, et al, are open source projects, Angular in particular, needs to work with NodeJS and Typescript ecosystems, which almost immediately demands dealing with node_modules dependencies if Bazel is to be used with it. You see to imply this was a case of Bazel folks somehow being blind sided by these requirements, but it's more a case that step 1 was to make a version of Blaze that works outside Google, step 2 was to make it work for non-monorepos and non-single-version dependencies, and step 3 was to make it integrate with alien package management ecosystems. Actual support for the things you claimed is quite good now, and that's my point. You posted a number of claims that are now no longer true as of version 1.0. Yeah, a year ago, things were bad, but then again, it was a project at beta level in rapid development, and pretty much for early adopters.

adev_ 7y ago

> Seems to me your making a lot of claims about bazel without having used it I lost literally weeks of my life to make Bazel work in external build systems for tensorflow and others. And I am apparently not the only one : https://archive.fosdem.org/2018/schedule/event/how_to_make_package_managers_cry/ https://archive.fosdem.org/2018/schedule/event/how_to_make_p... Then I don't allow you to tell me "not having used it". All the answers you gave are "fixes" that have been made after the community complained. Fixes that were sometimes not even documented.

cromwellian 7y ago
Bazel is based on Blaze, which is Google's internal mono repo build system. But Angular, Kubernetes, Tensorflow, et al, are open source projects, Angular in particular, needs to work with NodeJS and Typescript ecosystems, which almost immediately demands dealing with node_modules dependencies if Bazel is to be used with it. You see to imply this was a case of Bazel folks somehow being blind sided by these requirements, but it's more a case that step 1 was to make a version of Blaze that works outside Google, step 2 was to make it work for non-monorepos and non-single-version dependencies, and step 3 was to make it integrate with alien package management ecosystems. Actual support for the things you claimed is quite good now, and that's my point. You posted a number of claims that are now no longer true as of version 1.0. Yeah, a year ago, things were bad, but then again, it was a project at beta level in rapid development, and pretty much for early adopters.