Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Please – A cross-language build system

please.build

Post reply on HN
Print view View original

231–240 of 257 posts

Re: Please – A cross-language build system

#231

Post by tatskaari »

haberman wrote: post #155
moonchild wrote: post #142

Earlier quoted context omitted.

> The Makefile abstraction is "run this command when the output files don't exist or are older than the input files." You manually specify every tool to be run and all of its arguments. > The BUILD file abstraction is something like "I am declaring a C library with these sources and headers." This is wrong. Even ninja has generic rules. Here's an example of a minimal makefile: OBJ = src/a.o src/b.o src/c.o libfoo.so:…

> Here's an example of a minimal makefile: Your example does not contradict what I wrote. You manually specified the tool to be run ($CC) and all of the arguments to that tool. It's true that there is a level of indirection through the $CC variable, but you're still operating at the level of specifying a tool's command-line. > There's no reason this shouldn't be possible with make; it just hasn't been implemented so.…

Please takes sandboxing a bit further using kernel name-spacing to isolate builds and tests. It's an opt-in feature but you can bind to port 8080 in your tests and run them in parallel if you do ;)

Re: Please – A cross-language build system

#232

Post by pbronez »

throwaway894345 wrote: post #30
mdoms wrote: post #11

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.

Typically (general purpose) build systems make you choose between reproducibility and performance. Please and other related tools aim to change that (however, in my experience they all fail for one reason or another—not because the problem is inherently intractable but rather because these tools are underinvested-in such that they’re infeasible for smaller organizations to operate and larger organizations can afford…

I think this “missing middle” is a common pattern in expert tools. The economics are challenging because people quickly move through the skill level where the tools are most useful.

Re: Please – A cross-language build system

#233

Post by oblio »

tatskaari wrote: post #42
mdoms wrote: post #11

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.

Hey, I maintain please and will be the first one to admit we’re not the best at marketing it. We’ve mostly been focused on getting it up to scratch and only recently have we been trying to publicise it. With that being said I have put a good amount of work into the QuickStart. The code labs are designed to get you up and started in an inviting way. If you have any specific feedback about your QuickStart experience I’…

You should also say upfront that it doesn't support Windows.

Re: Please – A cross-language build system

#234

Post by tatskaari »

dsagal wrote: post #198

Is there any help from Please on building TypeScript projects faster?

It's pretty easy to wrap the typescript compiler however I've not seem many people use pure TS like that. Mostly people want to use webpack and TS together. Unfortunately webpack doesn't expose anything that would allow us to incrementally build a webpack bundle.

Re: Please – A cross-language build system

#235

Post by zulu-inuoe »

scaladev wrote: post #223
iab wrote: post #23

Earlier quoted context omitted.

Plz is great for c++, and has a better workflow (IMO) vs (e.g) Cmake. The skylark-like syntax is easier to reason through than cmake generative expressions. Also the use of “plz run” vs “cmake -g; make; run”

cmake generator only needs to be run once per project. After that you use make or ninja directly, and it regenerates the build files if necessary. I can't say it's a strong argument against cmake.

This added user complexity is exactly the argument for plz, though. One of the ideas touted is (to my mind) tight integration, in that plz knows how to handle everything. Whereas cmake just makes project files and leaves it at that.

Re: Please – A cross-language build system

#236

Post by bertr4nd »

archangel_one wrote: post #112
karmakaze wrote: post #59

Earlier quoted context omitted.

What was/is the motivation for this build system that an existing one doesn't satisfy?

We wanted something like Blaze (Google's system); at the time we were using Buck which didn't satisfy us (e.g. only one output per genrule, no directories; and it was more or less impossible to write first-class support for a new language without modifying the core system). Subsequently Bazel got released but we still find that a bit lacking in some areas; e.g. the CLI, the JVM reliance and some of Starlark (e.g. it…

I’m not sure if the feature was added after you started building Please but Buck does support multiple outputs from a genrule now. It’s kind of hacky though; you write a genrule that produces a directory containing said multiple outputs, and then you can write rules to extract the subcomponents. (I don’t know why I feel compelled to point this out. I worked on Buck for about a year, several years back. )

Re: Please – A cross-language build system

#237

Post by nickelpro »

zulu-inuoe wrote: post #235
scaladev wrote: post #223

Earlier quoted context omitted.

cmake generator only needs to be run once per project. After that you use make or ninja directly, and it regenerates the build files if necessary. I can't say it's a strong argument against cmake.

This added user complexity is exactly the argument for plz, though. One of the ideas touted is (to my mind) tight integration, in that plz knows how to handle everything. Whereas cmake just makes project files and leaves it at that.

Are build tools targeted at end-users? Cmake is better for me, the developer, the person who has to build the software

Re: Please – A cross-language build system

#238

Post by csdigi »

Ericson2314 wrote: post #81
tatskaari wrote: post #42

Earlier quoted context omitted.

Hey, I maintain please and will be the first one to admit we’re not the best at marketing it. We’ve mostly been focused on getting it up to scratch and only recently have we been trying to publicise it. With that being said I have put a good amount of work into the QuickStart. The code labs are designed to get you up and started in an inviting way. If you have any specific feedback about your QuickStart experience I’…

This makes me sad. You hopefully have tried out many other build systems by now, been frusted with all of them, and only then made your own. And with all that experience with the status quo, marketing should be easy. If you haven't done that, this project is a net- negative on the world, because the proliferation of build systems exacerbates Conway's law and balkanizes our software commons. NIH in FOSS is not free.

I am not an author, but was around when we decided to create Please in 2015.

When we created Please we were currently using Buck from Facebook. As has been covered elsewhere at the time it had some limitations which meant that it was getting more and more expensive to workaround (no multiple outs from rules so doing things like sourcemaps was hard etc). We had previously migrated from a set of disparate build tools (Gradle, Gulp etc) to Buck after evaluating it against Pants (we actually trialled our repo with both).

We all had experience with Blaze (Bazel did not exist in 2014/2015) and wanted to get closer to the experience we had in Google, hence the final decision to build our own. At the time we rolled it out we had full Buck compatibility (and actually most of our engineers did not notice initially). Once we were happy it worked, we migrated in full to Please.

Overall it allowed us to provide much better tooling for our developers (queries on the build graph for smaller CI/CD footprints, coverage in all languages, and for rules that can output multiple languages (like protocol buffers) we only build variants in the requested languages rather than all languages).

If Bazel had been open-sourced and easy to extend at the time we would certainly have looked to adopt and improve it (as we did with Buck at the time). But by the time they open-sourced it the two system had diverged in their approach and use cases.

I (obviously somewhat biased) think having multiple principled build systems which prioritise the needs of different communities is good for the ecosystem overall (and allows the sharing of good ideas such as the Remote Execution Interface).

Re: Please – A cross-language build system

#239

Post by panda88888 »

klodolph wrote: post #190
panda88888 wrote: post #156

Earlier quoted context omitted.

I am interested in setting up cross compiling environment with Bazel. Do you have any recommended documentation that I can read?

The documentation is not so great. What I’m doing is enabling platforms ( https://docs.bazel.build/versions/master/platforms-intro.htm... ), defining the OS and CPU target for my system, copying the configuration out of Bazel’s “local_config_cc”, and modifying it to fit my use case. This didn’t take me very long, but it’s also not the first time I’ve done it.

Thanks! I agree that the documentation isn’t that great and I feel there are lots of holes.

Re: Please – A cross-language build system

#240

Post by tuatoru »

klodolph wrote: post #86
rthomas6 wrote: post #67

I come from a sofware world not typical for HN. I am a (very) low level software and FPGA guy. Despite my best efforts, I don't understand: What do any of these tools do that Make does not? Are they faster and easier to use? Do they work better?

Make has a laundry list of problems: - Cannot handle multiple outputs for a single rule - Does not rebuild when flags change - Make rules may contain implicit dependencies - Slow for large codebases - Does not understand how to build for multiple platforms, sucks for cross-compiling - Recursive make sucks (job control does not work across recursive invocation boundaries) - You must create output directories yourself…

> Make has a laundry list of problems

So do C, and Bourne shell. And SQL.

And yet, here we are. Are the benefits enough to overcome incumbency?

Post reply on HN