Live data from Hacker News

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

apenwarr.ca

41–48 of 48 posts

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

#41

> 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.

That's a double-edged sword: because make doesn't "support" your language things get hairy (think sed) as soon as you need to support anything non-trivial (say header dependency extraction for C/C++). Doing it in a portable way is often just impossible (try to do header dependency extraction for MSVC on Windows with make).

So ideally you want both ad hoc rules (like make) as well as some king of build system plugin support which allows you to write more complex rules in something more powerful and portable. This is the approach we have taken with build2[1].

[1] https://build2.org

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

#42
post #24

Earlier quoted context omitted.

You can run the build in a container without network access. Admittedly, neither make nor redo make it any easier to create such a container, but they don't make it harder, either.

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…

Some of those sound like the benefits of Makefiles, actually. But if it floats your boat...

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

#43
post #40

Earlier quoted context omitted.

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 s…

This has got nothing to do with my point of using a changing code base to compile against.

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

#44
post #42

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…

Some of those sound like the benefits of Makefiles, actually. But if it floats your boat...

Which of these things is a benefit of make?

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

#45
I played a bit with redo some time ago. It hit a chord with the way I like to do things (small, minimalistic tools that do one thing right). But it was hard to find my way around it, and for certain things (commands that produce more than one "product") the only answers were, in all honesty, hacks. Best example I remember now is bison, which produces a .c and a .h file. The hack was to produce a tar which contained the .c and .h files, declare that as the output from bison, and then have rules that state that your .c and your .h depend on the tar. Blergh.

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

#47
post #42

Earlier quoted context omitted.

Some of those sound like the benefits of Makefiles, actually. But if it floats your boat...

Which of these things is a benefit of make?

#1 (but they're called Makefiles), #2 (implicit rules), #5 (with -j on NUMA), and (unless you overuse the GNU function extensions) #8.

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

#48
post #40

Earlier quoted context omitted.

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 s…

This has got nothing to do with my point of using a changing code base to compile against.

This has a lot to do with your point that "they deserve it" being not useful to improve things. How about we give that project a tool that just doesn't have this dangerous functionality?
Post reply on HN