[skore]

I just wish someone would RIIR Gnu make.

I use it heavily and think it's extremely underappreciated, so instead of reinventing it, I would like to build on it. But - trying to extend the old C codebase is daunting. I'd even be happy with a reduced featureset that avoids the exotic stuff that is either outdated or no longer useful. The core syntax of a Makefile is just so close to perfect.

(I wrote about some of this in the remake repo: https://github.com/rocky/remake/issues/114 )

[dataflow]

You had me until

> The core syntax of a Makefile is just so close to perfect.

I'd argue what is close to perfect is much of the underlying model/semantics, and what is terrible is very much the syntax. I've long wanted to make something similar to Make but simply with better syntax...

[skore]

To me, the core of the syntax is:

    target: prereq | ooprereq
        recipe

In my eyes, the most important thing when building something that is complex is the dependency graph and it makes sense to make the syntax for defining the graph as simple as possible. I think the make syntax just nails it and most of the other approaches I have seen so far add complexity without any benefit. In fact, most of the complexity they introduce seems to stem from confusion on the side of the developer being unable to simplify what they're trying to express.

At the level of variable handling and so forth, make is slightly annoying but manageable.

Anything beyond that - yeah, I'm with you, a lot of that is terrible.

[cat199]

> I've long wanted to make something similar to Make but simply with better syntax...

If you haven't, I'd suggest having a look at pmake (sometimes packaged as 'bmake' since it is the base 'make' implementation on BSDs) - the core 'make' portions are still the same (like gmake extends core 'make' as well), but the more script-like 'dynamic' parts are much nicer than gnumake in my opinion. It also supports the notion of 'makefile libraries' which are directories containing make snippets which can be #include's into other client projects.

freebsd examples:

manual: https://www.freebsd.org/cgi/man.cgi?query=make&apropos=0&sek...

makefile library used by the system to build itself (good examples): https://cgit.freebsd.org/src/tree/share/mk

[rwmj]

I had a go at making an experimental tool with a better syntax, fixing a lot of the obvious problems (whitespace, $ having a double meaning, etc). https://rwmj.wordpress.com/2020/01/14/goals-an-experimental-...

[Ericson2314]

So you want ninja?

[matheusmoreira]

Yeah, GNU Make is actually a functional programming language. When I discovered this, I almost reinvented parts of autoconf in GNU Make. It's like trying to write a complex project with C preprocessor macros! It was a lot of fun.

GNU Make is hurt by its minimalism. Doing anything interesting in pure GNU Make is a herculean effort. Even something simple like recursing into directories in order to build up a list of source files is extremely hard. Most people don't even try, they would rather keep their source code tree flat than deal with GNU Make. I wanted to support any directory structure so I implemented a simple version of find as a pure GNU Make function!

At the same time, a reduced feature set would be nice. GNU Make ships with a ton of old rules enabled by default. The no-builtin-rules and no-builtin-variables options let you disable this stuff. Makes it a lot easier to understand the print-data-base output.

> The core syntax of a Makefile is just so close to perfect.

It's very simple syntax but it has its pain points. Significant spaces effectively rules out spaces in file names. It also makes it much harder to format custom functions.

Speaking of functions, why can't we call user-defined functions directly? We're forced to use the call function with the custom function's name as parameter. Things quickly get out of hand when you're building new functions on top of existing ones. I actually looked up the GNU Make source code, I remember comments and a discussion about this... It was possible to do it but they didn't want to because then they'd have to think about users when introducing new built-in functions. Oh well...

[moonchild]

> something simple like recursing into directories in order to build up a list of source files is extremely hard

What's wrong with shelling out to find?

[nicoburns]

Have you seen Just? https://github.com/casey/just

It's make-like but supposedly improves on some of the arcane aspects of make (I can't judge how successful it is at that as I've never used make in anger).

[jamwaffles]

We use it a bit for https://github.com/embedded-graphics/embedded-graphics and I have to say I love it. It's just the right balance between configuration variables/constants and "a folder full of bash scripts". I highly recommend giving Just a try.

[bluejekyll]

One of the reasons I know I still rely on Make instead of Just, is about how available make is, and pretty much any tool (be it a new implementation of make in Rust or Just) will have to deal with the fact that make is already a default on so many systems.

That makes make a great entry point for any project. Does anyone have a general suggestion about how to work around this? The goal being, sync a project and not need to install anything to get going. One thing I do sometimes is to use make as the entry point, and it has an init target to install the necessary tools to get going (depends on who I know to be the target audience).

[cytzol]

I love Just, but I love it because it's not a build system — I already have a build system, I just need a standard "entry point" to all my projects so each command a user could use to interact with the actual build system is in the same place for each project. I wouldn't build, say, a C project with Just and Just alone, where it tracks the dependencies between files and only rebuilds what's necessary.

So while it's replaced one use of Make for me, I can't rightly call it a Make replacement.

[candied_scarf]

i wont use this because the author sucks up all justfiles files with no way for a user to opt out and isnt fully clear on this. use it on some private or company thing that accidentally goes public, oops he has your file now in his repo.

if it was opt-in to him monitoring i might be more open. maybe i should fork and change the filename to keep this from happening

[skore]

I've seen it before but discarded it because since my workflow is heavily file-based, I DO need makes capacity as a build system, not just a task runner. Will check it out to see whether that changed.

edit: Yeah, I can't see how I can make it work for a file-based approach.

[stefan_]

There is kati from Android:

https://github.com/google/kati/blob/master/INTERNALS.md

This takes your existing Makefile(s) and produces a ninja build file. Not sure if Android still uses it or it is all soong now.

[coldtea]

>The core syntax of a Makefile is just so close to perfect.

That's about the last thing I would call it.

[boris]

Allow me to suggest build2 (the build system part) as another alternative. You would probably be first interested in ad hoc recipes: https://build2.org/release/0.13.0.xhtml#adhoc-recipe

[skore]

Very VERY interesting!

The one thing that I'm currently struggling to find information on is dynamic dependency handling (dyndep in ninja terms).

Is that something that build2 covers as well? Any resource you could point me to?

[deknos]

https://github.com/taskctl/taskctl

[skore]

That looks very good! I wonder if I can make it fit my file-based approach.

edit: Yeah, doesn't seem like it.

[JoshTriplett]

Someone is working on this, and could use help: https://github.com/michaelmelanson/fab-rs

I would love to see this completed to the point of passing the GNU make testsuite. Having make as a modular library would be wildly useful.

[JetSpiegel]

There's always ninja.

https://ninja-build.org/

[layoutIfNeeded]

In case anyone would attempt this: please make quoting right.