How big does the project have to be in order for this system to have benefits over Make?
Please – A cross-language build system
141–150 of 257 posts
Re: Please – A cross-language build system
#142I 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?
Makefiles operate at a low level of abstraction. 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. These tools operate at a higher level of abstraction. The BUILD file abstraction is something like "I am declaring a C library with these sources and headers." The build system then turns…
> 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: $(OBJ)
$(CC) -shared -o libfoo.so $(OBJ)
There's no reason this shouldn't be possible with make; it just hasn't been implemented so. Do bazel/buck/please actually do this? As far as I know tup is the only tool that actually verifies inputs/outputs of rules, and it needs FUSE to do so.
> For example, unless you implement your own header scanning (or manually list your header dependencies) "make" won't know to rebuild a source file when a header changes.
At least with GNU make, it's very easy:
CFLAGS += -MMD
-include $(patsubst %.o,%.d,$(OBJ))
Make has problems, but the ones you listed aren't they.
Re: Please – A cross-language build system
#143Earlier quoted context omitted.
I've only used Bazel in anger (in a medium-small sized project); I've found it really frustrating because it effectively has two separate languages (inside build files and in custom rules), even though it's both Starlark. It's especially terrible for doing things that Bazel didn't already know about (i.e. running shell commands to generate things, even if you could tell Bazel all the inputs and outputs). We wanted to…
What do you mean? Genrules are very good at running she'll commands (or even entire executables). By custom rules do you mean macros, or full on custom rules?
Genrules are okay for commands, but most things I want to do end up being tiny shell scripts, which isn't a great fit.
I mean full on custom rules, exactly because of the inability for genrule to span more than one command (so we end up having to generate tiny shell scripts and running them).
I've also had issues debugging things any time I've tried to use genrule; the error messages tend to be unhelpful in my experience (though that's been a while and I don't recall the details). Things that look like they'd do what I want would just not work in unhelpful ways, and interrogating the system usually didn't work until there were no errors (at which point I wouldn't need to interrogate it anymore…)
Re: Please – A cross-language build system
#144Earlier quoted context omitted.
The JRE is 655.8M on my system.
And I would have considered that to be large 20 years ago, because it would have filled an entire CD-ROM disc, and it would have taken over five hours to download. However, I still have somewhere over 100 GB free on my seven-year-old laptop, and the download will take me ~40 seconds. But even if the 600MB were a problem, Bazel doesn’t need an external version of the JVM. It bundles its own, and fits the whole thing i…
50mb for a build tool is still ludicrous. Very few product codebases will ever reach that size.
In my experience there is a strong correlation between executable size and how hard it is to unravel any issue that arises in it.
Re: Please – A cross-language build system
#145First thing every software engineer does after leaving Google is rewrite Blaze. Just like every site reliability engineer rewrites borgmon. What I chose to do myself was make Blaze happen using a Makefile config. There's a blog post somewhere where Google talks about why they switched from GNU Make to Blaze c. 2006. if I remember correctly it basically boiled down to not having strict dependency checking. So I though…
Reading your words, it looks like you have made a kind of make replacement that just works. Following your link, it looks like... what ? I don't know, some tool that checks some build configuration, augments C and postprocesses executable files?
(Looking at https://github.com/jart/cosmopolitan it's an interesting hack. Might be useful in some cases, for example command-line tools like git.)
Have you made something that looks like a better make? If so, it would be nice to know more. Thanks.
Re: Please – A cross-language build system
#146At some point it becomes actively harmful to build and publicize tools that further the fragmentation of an ecosystem. We need a unified build system, not yet another build system. To get there we have to contribute to existing tools to keep making them better.
Re: Please – A cross-language build system
#147I love build tools, and work with them professionally, and this tool seems to be getting one thing quite right: it is not injecting itself into the dependency resolution process. Where I see build tooling fall down is where they try to replace the idiomatic dependency modeling tools that exist in each language. The build logic and CLI experience looks to be well thought out. I really like the native sandboxing suppor…
I read Please website (main page, "Getting Started" and FAQ), and still ain't sure about the benefits.
To the maintainers of Please: please make cases and user stories, also comparisons with other build tools.
Many visitors will jump on each "comparison with tool X" where X=each of the current tools I'm familiar with. Only "Bazel, Buck or Pants" are mentioned. Okay no JVM, looks like Please is a better thought out Blaze/Buck.
Please mention CMake and others, like the C/C++-oriented http://floooh.github.io/fips/ (a high-level build system "similar to Rust’s Cargo or Javascript’s NPM, but for C/C++ projects.").
Re: Please – A cross-language build system
#148Earlier quoted context omitted.
What do you mean? Genrules are very good at running she'll commands (or even entire executables). By custom rules do you mean macros, or full on custom rules?
Genrules are okay for commands, but most things I want to do end up being tiny shell scripts, which isn't a great fit. I mean full on custom rules, exactly because of the inability for genrule to span more than one command (so we end up having to generate tiny shell scripts and running them). I've also had issues debugging things any time I've tried to use genrule; the error messages tend to be unhelpful in my experi…
Genrules can run shell scripts though, like most of the time my genrules invoke an arbitrary python script. Shell would work much the same.
What do you mean by a "command"? I'm very confused by the nomenclature here.
Re: Please – A cross-language build system
#149Can somebody sell me this tool while comparing it to `make`, or Elixir's `mix`, or Rust's `cargo`?
Or CMake or the C/C++-oriented http://floooh.github.io/fips/ (a high-level build system "similar to Rust’s Cargo or Javascript’s NPM, but for C/C++ projects.").
Re: Please – A cross-language build system
#150> If you're familiar with Blaze / Bazel, Buck or Pants you will probably find Please very familiar Yes, so why would I use Please over any of them? I've spent close to 10min reading and have no idea why this exists or why anyone would use it. It looks like Bazel with a different config format, in which case why wouldn't one just use Bazel?
I hate bazel with passion, I have to use it at work on really large project, and the UX is so wrong... built for google by google and my CTO thinks we can be google if we use it...
What specifically about the UX is annoying to you? I'd be interested in hearing what could be done to improve the experience. Is it just writing BUILD files or is it the cli interface?