[dwheeler]

Sadly, the POSIX specification for "make" is notoriously limited. They only spec'ed what everyone could agree on, and that wasn't much. I'm sure there are cases where a make that only implements the POSIX spec is fine.. and if this is useful, great!! However, many projects that use "make" will outgrow it. I think many people just assume GNU make when they use a make; GNU make has lots of additional capabilities that turn out to be useful, and it runs practically everywhere.

Your mileage may vary.

[ori_b]

> Extensions from a future POSIX standard have been added. Note that these are subject to change until the standard is finally published.

The extensions listed cover most of what I'm currently missing from posix make.

[hvdijk]

Even for those that do not assume GNU make, this may not be enough. GNU Autotools are not limited to running on GNU make, but this make does not implement everything used by Autotools. The first thing I noticed it does not handle is VPATH (https://www.gnu.org/software/make/manual/html_node/General-S...) which is used by Autotools for out-of-tree builds (mkdir build && cd build && ../configure && make as opposed to ./configure && make).

[zxwrt]

But out-of-tree builds feature is optional, right?

[hvdijk]

It depends on the package. As far as Autotools itself are concerned, yes, users are free to choose whether to do in-tree or out-of-tree builds, but some packages require one or the other.

[chubot]

Yeah I'm left scratching my head at the purpose of this project.

I wrote 3 GNU makefiles from scratch (a few hundred lines each) starting in ~2016 for https://www.oilshell.org/, and regret it. I switched to Python + Ninja, and I should have just used that all along.

So I think GNU make is already pretty old and regretted, and POSIX make even more so.

CMake + Ninja seems be pretty common these days, but for my project Python works fine, and is a lot simpler. CMake is also a bad (shell-like) language, but I'm pretty sure it's better and more featureful than GNU make (i.e. you're less likely to need to switch build systems/languages due to a new requirement)

This thread has some interesting experiences ... it does seem like there needs to be a better high level language to generate Ninja

https://lobste.rs/s/7svvkz/using_bsd_make#c_bfwcyc

Also, for portability I just generate a shell script instead of Ninja (even though Ninja is extremely portable and has multiple implementations now). For tarball distributions you probably don't need incremental builds.

All the user should need to compile software is a shell, not ANY make!

[frankohn]

My experience aligns well with your. For any moderately complex project makefiles are inadequate and trying to make them work is a frustrating experience even in GNU make is pretty capable.

Ninja is a fine tool but it requires an higher level language to generate it's build files.

Cmake is just horrible, I just cannot stand it. I choose Meson instead and I am quite happy with it. Meson developers focus a lot on doing the right design decisions. They keep the language very simple and offer mostly one logical way to do a thing and Meson ensure it works right in every circumstance. Yet it offers advanced options when they are required but they are always well thought out.

If you compare meson to make at first you may think make is more flexible but ultimately it leaves to you many problems it doesn't solve and it turns out to be inadequate.

With make, declare automatically dependencies from header files? You are alone, that's your problem. There are some tricks using GCC but they looks like hacks. Maintain projects build logic across subfolders? That's your problem. Make only provide a very rough, inadequate mechanism.

Want to do parallel build by respecting dependencies across folder? Sorry, that's your problem but it may work using some tricks.

Want to build out of tree? Hmmm not supported in a standard idiomatic way. You need to use tricks.

How you create a static library in a cross-platform way? That's your problem. The same for shared libraries.

Personally I think that make is an obsolete tool whose design is inadequate very much like CVS that was replaced by git.

To me the only downside of Meson is that it requires python but I can accommodate with that.

[zxwrt]

> To me the only downside of Meson is that it requires python but I can accommodate with that.

Check out https://git.sr.ht/~lattis/muon

[frankohn]

Thank you, that looks interesting. I will check how it works with my projects.

[qznc]

https://xmake.io/ kinda is Meson but with Lua instead of Python. Lua is embedded so no external dependency.

[frankohn]

Thank you, that looks interesting too. In addition I like Lua because is much more light weighted than python and being embedded is nice to reduce dependencies.

The only problem I see is fragmentation. People are already considering cmake as the de facto standard despite all its flaws. If the cmake alternatives are too fragmented it will play in favor of cmake.

On the other side projects like xmake are interesting propositions. I will have a look at it in any case, thank you.

[kevin_thibedeau]

How do you do parallel builds with a shell script?

[chubot]

Right now I don't, because the project takes ~30 seconds to build serially... There are a few options:

1. Put the Ninja support in the tarball (which is trivial, but I guess I was paranoid about the extra dependency for a low level tool like shell). I think Ninja is supported everywhere now, including on Windows and BSDs. It's easier to build that GNU make itself, etc.

2. The last time I looked, the toybox project had some sort of "parallel job server" type thing in shell, to avoid GNU make.

3. Maybe do something simpler with "xargs -P" (non POSIX)

I'd probably go for the first option just because it's the least custom code to solve this particular problem. If the build was slower, it might be different ... although if speed is really an issue, then Ninja is the best option out of all of these, AND GNU make!

----

edit: I should also note that in practice I think many users and especially distros do NOT pass -j $N to GNU make because it's not reliable. If upstream didn't test with it, there can be bugs that result in incorrect builds. So distros often just use serial builds.

On the other hand, paralllel builds with Ninja are the default, so upstream will have tested in that mode.