Goals: Red Hat Developer Working On New Tool To Improve Upon Make

[mkrupcale]

It would be nice to see a C/C++ equivalent of the cargo build system. As, in, doesn't have to be appropriate for all projects ever written, but is extremely low maintenance and parses the source to automatically resolve dependencies.

build2 is a a cargo-like build toolchain written in C++. It is like make in the sense that its build files have a notion of targets, prerequisites, and rules. However, it does extract some source code dependency information such as the usual header dependencies and even C++20 modules. Plus it's highly extensible (especially with the introduction of build system modules in v0.12) and can deal with generated source code dependencies defined by rules such as the in module.

Then there are package-level dependencies which are dealt with using a normal package manifest file analogous to the Cargo.toml file.

Full disclosure: I'm the build2 package maintainer on Fedora.

[starshipeleven]

Looks interesting.

I admit though when I first saw the post, my first thought was "they're going to incorporate Make into systemd."

It's probably going to happen when it's ready. All praise its holy name.

[jason.oliveira]

Why work on 40 year old codebase if you can avoid it? Make isn't a kernel.

JWZ wrote an article about kids like you.

[marek]

Is it gonna compile faster than ninja? If yes, can you prove it? If not, why care?

[ssokolow]

JWZ wrote an article about kids like you.

CADT is about the maintainers of a project hitting the reset button whenever the maintenance tasks get un-fun. If this weren't an effort to explore "Make, but designed with what we learned from 40 years of having it", NIH would be the correct term.

[jaypatelani]

They can just use PkgSrc make https://opensource.com/article/19/11...c-netbsd-linux

[starshipeleven]

JWZ wrote an article about kids like you.

Your reading skills suck.
That guy stuck in a "get off my lawn" mentality is complaining about people not looking at his bug reports and then closing them after a rewrite, he is not against rewrites.
If someone rewrote stuff and checked that his bug was not present anymore it would be called refactoring and that's what serious projects do and it's perfectly OK.

Also I'll tell you that he is an idiot if he seriously thinks issues that plagued humanity since the beginning of time are only of younger people. This extends on you too of course.

[Jabberwocky]

To answer a few questions:

It's an experimental tool designed to explore new directions for a make-like tool. It absolutely does not work like the other tools people have mentioned. Free software continues to get better by people doing experiments, and we see what works and what doesn't work. Maybe goals won't work, in which case I'll have wasted a few weeks over Christmas. Maybe it'll be picked up in another tool. Maybe goals will become incredibly successful and displace those other tools (this is very unlikely). I'd advise people to actually watch the video, by comparing the tool to CMake and meson - which is literally mentioned in the first slide of the video - it shows you didn't do that.

Why not modify "make"? The syntax is totally different and has to be that way in order to solve the problems that make has. No such change would be acceptable to make.

The code is fully open source. The license is GPLv2.

Welcome to Phoronix. Thanks for your research and talk/demo.

I've been using the following method for large projects.

1. make -> build -> docker -> dependency & compilation
2. make -> test -> docker -> unit and mock tests
3. (optional) make -> integration tests
4. make -> publish

My systems only run on Linux-AMD64. I target many Operating Systems and Architectures via cross-compilation. Docker supports most dependency management tools most developers like to use e.g. cargo/npm/go-modules. I've used the same approach for macOS-AMD64 but it's usually once off projects. in theory this approach works on many other operating systems in case cross-compilation is not a option or advanced integration tests are required. For my projects integration testing is only possible after (internal) publication.

I agree with you, Make really has some tricky gotchas but it is a really good tool overall. Good luck with Goals!

[g04th3rd3r]

GNU make is quite featureful, ubiquitous, free, and most importantly, thoroughly debugged. Any deficiencies can easily be addressed with a meta-make utility that generates a makefile, and then calls make. I wrote one myself about 20 years ago as a bash script, and use it to this day with minor upgrades over the years. It makes trivial the building of multiple versions of executables, libraries, and directory hierarchies from a single meta-make file which is actually just the top portion of a GNU makefile.

It's almost always better to build on proven infrastructure than to reimplement.

[juarezr]

Neither can I, but I did say "If Goals can be a drop in replacement". IF is the keyword.

I was also wondering about the dependencies requirement too.

I also saw that "I hope it's like Cargo" post and thought to myself: "Iz you a tard?" due to all the places and languages that make is expected to work with.

It does aim to solve shell and scripting issues without requiring people to know about hacks like .PHONY and whatnot. If it can do that while acting as a drop-in replacement, then it is worth the effort and will have mine and a lot of other's gratitude. There's another IF there.

What I think about? Let's not go there

Yeah!
It would be wonderful IF, but I think that is NOT !!!!