Until CMake stops having so many pain points, I imagine this will only get worse, I feel.

normal make has built-in rules for C

Any examples of pain points with CMake? I use it every day and rarely have issues, yet I seem to see complaints online rather often.

easy, CMake 3.xx or higher is required.

So… a build of CMake from within the last 8 years? Seems like a reasonable requirement.

I haven't tried CMake recently but I remember using it in 2012 and it was awful - the documentation was unhelpful and as soon as I tried to do anything not in the examples I was on my own.

I'd love to hear why you think that's a bad thing. IMHO it's a huge quality of life improvement over 2.x. Everything is part of a target (flags, defines, dependencies, etc.) and far, far fewer magic variables that pollute random projects whenever you try to compose them.

Cmake is confusing as all get out. Make follows the Unix philosophy of just doing one thing - call other programs. It comes with almost all tool chains you’d care about. You can pick up the basics of a makefile in an afternoon… I still don’t know where cmake functions come from, how you would know about them or how to write your own. Let alone which version is the right one.

It’s like jsonnet to me - if you need config files that make config files something has gone horribly wrong.

Then again, I stopped bothering trying to learn Cmake. If I see Cmake I don’t bother with the project so there’s that - and also not a fan of c++ so I am probably the wrong audience anyway.

What is confusing about CMake?

    cmake_minimum_required(VERSION 3.5)
    add_executable(exe file.cpp)

Do you think that's more complicated than the basics of a Makefile? [1]

[1]: https://anadoxin.org/blog/is-it-worth-using-make.html/

There are very few projects for which the above CMakeLists.txt would be enough. Once your project reaches a certain size you will inevitably end up in a part of CMake that is confusing.

Well, first argument is that it actually IS enough for lots of small tools, and second argument is that if it's not enough and must be extended, it still requires much less complication than an equivalent Makefile.

The comparable makefile:

    exe: file.cpp

Default rules take care of the rest.

And if you argue that the barebones example is insufficient for a real project: absolutely true. The same applies to your cmake example.

What do you mean it's comparable? Does it support multiple compilers? CFLAGS? Out of source builds? "compile_commands.json" generation? Automatic header dependency monitoring?

Also I've actually checked that Makefile, and it errored out (macOS):

    make: Nothing to be done for `exe'.

Here's what you get for free:

https://www.gnu.org/software/make/manual/html_node/Catalogue...

As you can see, it takes flags and compiler from the environment.

It seems that in order to use the default rules, the target name needs to have the same name as the source file, e.g.

    file: file.cpp

so specifying the "exe" filename as the output seems to be already a custom rule, so it doesn't seem to work without manually calling the selected compiler.

Another issue is that indeed, CFLAGS is supported by default (implicit) rules, but as soon as the user tries to build a custom rule (which is 99% of the time), the support is lost unless explicitly adding it.

Third issue is that it seems that implicit rules can be different by different implementations of make, i.e. BSD make can have different rules than GNU make. Even if we consider only one implementation, then default rules can be different to each platform. The docs state that the user should consider the output of the `make -p` command in order to see the rules, which gives me an impression that different implicit rules can exist on different Linux distros, depending on how `make` was compiled (not sure what is the de facto state).

I mean, it doesn't sound simple.

Yep. In practice, make gets bigger. cmake also ends up looking like this: https://github.com/opencv/opencv/tree/4.x/cmake

Trivial examples look nice enough in either system, big ones look bad in make and utterly fucked in cmake. Some of this is that people keep trying to write things in cmake scripts that should be external programs in a workable language.

To be honest, I'm not sure what is your point. Does the number of lines increase when the project complexity increases? Yes. Is CMake harder to read if the build system increases in complexity? Yes. The point of a minimal example when reasoning about CMake is to show that you get much more free stuff than in Make, not that it always stays small.

Putting an equal sign between CMake and Make, because the complexity increases in both, is pretty ignorant IMO. It's like saying "A car is no better than a bicycle, because both have problems with tires when driving long enough".

You have pasted a link to a complicated build system, which would be impossible to write and maintain in manual Make. It would require using Autotools. But then the Windows support would be dead. And lots of the files from the directory you've pasted are there in order to interface with hard-to-interface autotools-based build systems.

You can check out libarchive, which has support for both Autotools and CMake: https://github.com/libarchive . I'm not saying it uses both build systems the best possible way, but I pick CMake build over Autotools any day. What I get for free?

- I can open the project in my favorite editor and I have clangd working automatically,

- I can open it in Visual Studio, CLion, Eclipse, or whatever,

- I can create multiple configurations (release, debug, asan, clang, gcc, vs2019, vs2022), comple them all and run tests for all configs at the same time after each change,

- When changing the build system itself, I don't need to think in layers: first the M4 layer, then the bash layer (or was it sh?), then the /bin layer -- "is my option passed to "cp" accepted on OpenBSD or is it a GNU extension? I better quickly install an OpenBSD VM and check it."

Only if you are talking about bare bones POSIX compliant makefiles, which most definitly aren't, hello autotools.

> I still don’t know where cmake functions come from, how you would know about them or how to write your own.

There is a lot to criticize about CMake, but this is just RTFM level silly.

if you rarely have issues, either someone else dealt with them before you knew it, either your project is very simple, either your project doesn't ever change or all of the above.

I would like to work with your devops :)

Makefile.js here is actually Makefile plus configure, which makes more sense. The very need for configure is why a pure C project can be annoying to build, especially when you have a complex or auto-generated dependency or have to support multiple platforms.

Actually, no

Read the code. It literally reinvents all of GNU make...badly. Incl checking file dates to decide what to rebuild, implementing "clean", etc...

I've read the code and I know that it reimplements a substantial portion of Make. The point is however, this project doesn't work with a single Makefile either. Traditional projects would typically use configure plus (generated) Makefile, where configure is a shell script typically built from autoconf which is an abomination. In order to avoid autoconf some projects replace configure with other languages like JS. This project went further by merging that JS configure with Makefile. All of this hassle would be pointless unless you consider one important platform: Windows, where you don't natively have Make anyway.

You may still argue that this project still requires GCC and thus there should be Make even in Windows. That's reasonable, but right now I have GCC and Clang but no Make in my Windows console. If you can remove a hard dependency on Make with a reasonable cost (and I don't claim it's the case with this project, I would have used Ninja instead) it's pretty worthwhile in my opinion.

> All of this hassle would be pointless unless you consider one important platform: Windows, where you don't natively have Make anyway. [...] You may still argue that this project still requires GCC and thus there should be Make even in Windows.

I think that is a very good argument though: Windows doesn't have MSVC or any other compiler out of the box either, it is up to you to install the requirements so having Make as a requirement - especially considering how standard it is - is perfectly fine. Using something like MSYS2 gives you a Linux-like shell with all the tools you'd expect there.

There is no real reason to require Node aside from the author wanted to play around with it, the functionality that tool provides can be provided by other existing tools (Autotools, premake, CMake, meson/muon, etc) or even GNU Make itself (using its extensions that wont be compatible with other "makes" though).

(also while Autotools can feel a bit arcane, they have one feature that other similar tools do not have: you do not need to have Autotools installed to build the project, only some shell and some make, both being very standard in pretty much any unix-like OS and for Windows, well, see the first paragraph :-P)

Your notion of "standard" build environment with Make and POSIXish shell doesn't apply to MSVC. Well you do have nmake, but it is substantially different from Make anyway.

This is why i mentioned "for Windows, well, see the first paragraph" where i write "Using something like MSYS2 gives you a Linux-like shell with all the tools you'd expect there".

> where configure is a shell script typically built from autoconf which is an abomination

sorry, what is the abomination here?

Building (hopefully) portable shell scripts out of M4 macros is pretty hairy.

Portable to what though? Chances are the shell script code generated by Autotools is runnable in more places than Node.js.

Nobody cares about your doddering Ultrix system, old-timer.

Yeah that may well be. I'm just saying that it's a pretty horribly hacky way of making a portable script. It can be made to work, of course.

Right?

The idea that an x86 emulator, written in C99, would require node to build is a smell if I’ve ever smelled one.

If a dev can’t be bothered to use standard tooling, can he be bothered to write safe and performant C? Is this kind of “cleverness” running throughout his code? Maybe the build process is “too complicated” for standard tools, which is a problem for sure.

This is more of a question for the next developer who tries to pull something like this, I don’t really want the OP to be discouraged from continuing their work. Just, maybe next time, don’t force JavaScript into a round hole.

Node is standard tooling for younger devs -- who also find JavaScript more tractable than Make, CMake, or Autotools.

Tbh I'm kind of surprised they didn't use Gulp.

The only crime I see is how they wrapped this function https://github.com/nepx/halfix/blob/37a2d1394617397b817bbcd6...