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

The only build system that might someday replace make (2010)

apenwarr.ca

Post reply on HN
Print view View original

31–40 of 48 posts

Re: The only build system that might someday replace make (2010)

#31

Post by csande17 »

zellyn wrote: post #5
zellyn wrote: post #4

Earlier quoted context omitted.

Bazel is about as far from redo as you can get: they aim to solve very different problems. If you have a huge monorepo, and thus need distributed caching and distributed builds, and cross-language dependency tracking and incremental rebuilds, Bazel is for you. It has the advantage of being built _after_ Google understood all the places where lack of rigor or accidentally-too-capable build language features cause trou…

(At Square, we currently use Pants for our Java monorepo. Don’t do that; we’re switching.)

What's wrong with pants?

Re: The only build system that might someday replace make (2010)

#32

Post by zellyn »

csande17 wrote: post #31
zellyn wrote: post #5

Earlier quoted context omitted.

(At Square, we currently use Pants for our Java monorepo. Don’t do that; we’re switching.)

What's wrong with pants?

It's not widely used. Pure Java (rather than Scala) seems off the beaten track. The documentation is sparse. The IDE plugins are less capable, and less documented. It is sloppy about rigorously declaring needed files. It's slow just to start up. Actual Python rather than Starlark as a build language. The API from custom rules to internals is leakier (I believe). Bazel has a huge ecosystem of third-party rules to do all sort of things.

Re: The only build system that might someday replace make (2010)

#33

Post by tbrock »

elteto wrote: post #12
tbrock wrote: post #6

Earlier quoted context omitted.

We’ve been using it to build and deploy a ~500k loc JavaScript monorepo and I have an unpopular opinion about it. While I see the benefits of it for google scale, for us it’s just been one headache after another. Reimplementation of python for build file language? No thanks. Reimplementation of package managers? No thanks. Reimplementation of Docker? No thanks. It’s just another thing to learn, worry about, and disco…

Man, I'm sorry to hear about your experience :( I've used bazel in a different environment (C++) and it has been amazing (compared with other C++ build systems). Another comment below mentioned to stay away from bazel for anything else other than C++ (and maybe Java).

Thanks! As you probably know, c++ is definitely unique in that there is no built in way to manage dependencies and no de facto package manager. I would definitely use it for a cpp project.

Re: The only build system that might someday replace make (2010)

#34

Post by gravypod »

emmelaich wrote: post #30
gravypod wrote: post #28

Earlier quoted context omitted.

Blaze-like systems offer other benifits over makefiles that are, in their own right, amazing. 1. Distributing modules with BUILD files makes everything just work 2. You don't think at the level of commands/files, you think at the abstraction of targets. How targets happen in an implementation detail. 3. `select` for varying builds in a sane and readable way 4. Shared cache 5. Distributed build and test runner 6. Quer…

All those things could be done with redo with varying degrees of effort.

"Varying degrees of effort" and "the default" are very different. Do you have an example of those features that can be demoed in redo?

Re: The only build system that might someday replace make (2010)

#35

Post by 0xcde4c3db »

> with no baked-in assumptions about what you're building

This is probably the most underrated aspect of make that most other build systems immediately discard: it doesn't need to "support" your language or toolchain, which is really helpful when dealing with proprietary/in-house or otherwise unusual tools and processes.

Re: The only build system that might someday replace make (2010)

#36

Post by majidfn »

kinkrtyavimoodh wrote: post #3

What do people here think of Bazel [1]? In my understanding it is an open-sourced version of the build system that Google uses internally. [1] https://bazel.build/

We had a difficult experience with Bazel as well using it for a Go project. As mentioned it brings its own reimplementation of any compiler or package manager. So if there is a new feature from the language, you have to wait till the Bazel rules for that language gets updated, only then you can start using it.

For a Go project which the whole build command is a single line of `go build`, it takes lots of config files and configuration, and tweaking till you get the exact same result. Only till there is an update and the whole build crashes and you have to figure it out why.

To me m, Bazel is a great tool for Google or a project at the scale of Google projects. It is beneficial if you can benefit from distributed builds and caching layers. Only for a project big enough that those could make a difference.

But for all other projects, Bazel, felt like brining an 18-wheeler to go to grocery shopping.

Re: The only build system that might someday replace make (2010)

#37

Post by amiga_500 »

kubanczyk wrote: post #15

The biggest problem: "it can do everything make can do" This means it cannot enforce pinning-on-a-hash ('hermetic' builds in bazel lingo): if you allow dev team to say `git clone hxxp://whatever/whatever/master` somewhere in the bowels of the build system, they invariably go for it. It's easy, agile and it works (for months if not years). Result? On a large project, every week you get a build broken by some third-par…

Any project building against HEAD deserves it. Use a tag, in a config file. Not make's fault.

Re: The only build system that might someday replace make (2010)

#38

Post by raphlinus »

sansnomme wrote: post #29
raphlinus wrote: post #20

From my recent Twitter mentions: Build Systems à la Carte (2018). This presents a theoretical analysis of build systems (which they have defined broadly enough to include Microsoft Excel) and how to pick and choose the various properties they provide. This came up because I am promoting a conceptually similar unified theory of Reactive UI, which also has things in common with build systems. In fact, Svelte also happe…

Have you considered making a compiler plugin for Rust so Svelte style GUIs are possible? Reactivity should have first class support just like concurrency (which too have a runtime).

Wow, that's seriously off topic for a post about build systems, isn't it? :)

The Rust ecosystem does not support "compiler plugins" well (by contrast, this is a first-class concept in Kotlin). What is being actively pursued is "procedural macros," but we're running into the limitations of those - we're moving away from them for deriving lenses, for example.

I'm sure it would also bring up lifetime issues, but, to be fair, those are probably similar to issues for async, and that only took a couple of years or so to land. But people are actively thinking about using generators for UI.

I do think this is one of the open questions. It might be that really first-rate reactivity does require language support in some way. But this feels like like increasing the scope of an already possibly overambitious problem.

Re: The only build system that might someday replace make (2010)

#39

Post by sansnomme »

raphlinus wrote: post #38
sansnomme wrote: post #29

Earlier quoted context omitted.

Have you considered making a compiler plugin for Rust so Svelte style GUIs are possible? Reactivity should have first class support just like concurrency (which too have a runtime).

Wow, that's seriously off topic for a post about build systems, isn't it? :) The Rust ecosystem does not support "compiler plugins" well (by contrast, this is a first-class concept in Kotlin). What is being actively pursued is "procedural macros," but we're running into the limitations of those - we're moving away from them for deriving lenses, for example. I'm sure it would also bring up lifetime issues, but, to be…

To be fair, the UX for building Svelte-style GUIs is pretty unparalleled. It feels a lot like SwiftUI. The React variety with setState and Redux creates a ton of verbose code.

Re: The only build system that might someday replace make (2010)

#40

Post by theamk »

amiga_500 wrote: post #37
kubanczyk wrote: post #15

The biggest problem: "it can do everything make can do" This means it cannot enforce pinning-on-a-hash ('hermetic' builds in bazel lingo): if you allow dev team to say `git clone hxxp://whatever/whatever/master` somewhere in the bowels of the build system, they invariably go for it. It's easy, agile and it works (for months if not years). Result? On a large project, every week you get a build broken by some third-par…

Any project building against HEAD deserves it. Use a tag, in a config file. Not make's fault.

Segfaults, double-frees and buffer overflows are not C's fault. Any programmer using C deserves them. Right?

Happily, not eveyone thinks this way. That's why there is myriad of safe languages -- from Ruby to Rust -- which replaced C in many areas. Sure, C is still around, but many people prefer to give up some control for lots more safety.

The same logic applies to build systems. Sure, you can use "low-level" build system to hand-write gcc invocation in each project, but a bigger system makes your build files much safer.

Post reply on HN