11–20 of 257 posts
Changing build systems is hard, and getting buy-in from the team even harder - so you need to demonstrate value up front.
"Installing: curl https://get.please.build | bash" ...one can stop reading there: this product is not aimed at this community.
Glad it's getting some discussion on HN. Can't wait to hear other's experiences.
"Installing: curl https://get.please.build | bash" ...one can stop reading there: this product is not aimed at this community.
I don’t think this is a fair reason to write the tool off. They support Homebrew, and I’m sure will add other install methods in the future. Piping to bash is no worse than clicking “yes” on every step of an install wizard.
It's hard to tell what the value proposition is here, apart from vague hand-waving about parallelization. The quick start is not enough to get started actually building something. Changing build systems is hard, and getting buy-in from the team even harder - so you need to demonstrate value up front.
Without this tooling large organizations tend to silo which creates high engineering costs (every project starts from scratch, no shared frameworks/libraries, no standardizing around best practices, etc).
Please build is really fantastic and I loved using it. If it had better ide integrations I'd recommend it over bazel for oss work. It's extremely fast and we'll documented and the community seems very welcoming. Glad it's getting some discussion on HN. Can't wait to hear other's experiences.
Earlier quoted context omitted.
> Please (please.build) 'build' kind of indicates that
Unfortunately for those of us following HN through RSS readers (like Feedly) the URL doesn't show until you mouse over the link ... but even then, I agree adding that additional piece of information such as "build software" would be useful.
If someone had the same idea, please don’t hesitate sharing.
As a concrete example, one frustration at $DAYJOB is that building certain Google-released OSS is hard to integrate with our existing build system because Bazel is pretty opinionated about compiler-provided headers, output paths, etc. We're calling Bazel as a subprocess during our build and making various files available to it to make our compiler build visible to it, and then we pack up the results. I'm pretty sure if we somehow adopted Bazel for our entire build this would be much better - would it also be better if we adopted one of those other systems?
(Maybe one way of asking this is, are any of the corporate sponsors of Buck, Pants, or Please building third-party Bazel code from source? Or vice versa?)
A broader question: would it be worth defining a compatible subset of BUILD file syntax and library calls (i.e., not just Starlark but also the rules themselves for common things like building C libraries or JARs)?
Are we in the build-system equivalent of the vendor-specific C / C++ / UNIX implementations, and will a cross-vendor standardization effort emerge one day?