Live data from Hacker News

Using Make – writing less Makefile

text.causal.agency

181–190 of 200 posts

Re: Using Make – writing less Makefile

#181
post #122

Earlier quoted context omitted.

Make exists and is used widely and not because everyone's too inept to understand your points. The "assumption-making" build tools are the unicorns that inevitably cannot dominate because they're not generally applicable. The more they assume the more niche they become.

> The "assumption-making" build tools are the unicorns that inevitably cannot dominate because they're not generally applicable. They already do dominate. In the last bastion where make can be said to be popular (C) make has already lost to CMake and its usage shrinks every year [1] The situation is moving even faster for C++ [2] And for literally every other language in the systems programming space (C#, Swift, Rust…

cmake generates makefiles (or ninja) so it doesn't replace them. It replaces autotools - it works out what features a system has and what build flags to enable and from a generic description of your program it generates makefiles or ninja.build.

There's nothing fun whatsoever about fixing build problems with cmake - because you have to understand make/ninja AND cmake. It's slightly easier to understand than autotools, though, where one has the same problem.

Re: Using Make – writing less Makefile

#182
post #122

Earlier quoted context omitted.

Make exists and is used widely and not because everyone's too inept to understand your points. The "assumption-making" build tools are the unicorns that inevitably cannot dominate because they're not generally applicable. The more they assume the more niche they become.

Make is popular because many old projects use it and it comes pre-installed on Linux. It's a cultural thing.

It works on an enormous number of platforms with few dependencies. People have got these projects which build on everything from embedded platforms to mainframes and it has taken effort from many different people to achieve that.

So you might come up with some new thing that "Works For Me" and now all those people who are peacefully using the tool on their whatever platform have to fiddle with it to make it work again - or the person who made it work is no longer around and that platform loses support for the new versions.

When you say "cultural" you make it sound like people do things because they are ignorant and resistant to change but it's worth at least considering that their point of view is quite different.

Re: Using Make – writing less Makefile

#183
post #181

Earlier quoted context omitted.

> The "assumption-making" build tools are the unicorns that inevitably cannot dominate because they're not generally applicable. They already do dominate. In the last bastion where make can be said to be popular (C) make has already lost to CMake and its usage shrinks every year [1] The situation is moving even faster for C++ [2] And for literally every other language in the systems programming space (C#, Swift, Rust…

cmake generates makefiles (or ninja) so it doesn't replace them. It replaces autotools - it works out what features a system has and what build flags to enable and from a generic description of your program it generates makefiles or ninja.build. There's nothing fun whatsoever about fixing build problems with cmake - because you have to understand make/ninja AND cmake. It's slightly easier to understand than autotools…

> cmake generates makefiles (or ninja) so it doesn't replace them

That make happens to be a possible target of CMake is irrelevant to this discussion, it replaces the usage of make. make becomes an implementation detail.

No one should be writing Makefiles. You also shouldn't be using make as the underlying task runner but for a different set of reasons.

> There's nothing fun whatsoever about fixing build problems with cmake - because you have to understand make/ninja AND cmake

You need exactly zero understanding of make or ninja to use CMake. Ninja explicitly is not meant to be understood by end users, and only as a target for generators like CMake:

>Where other build systems are high-level languages Ninja aims to be an assembler ... it is designed to have its input files generated by a higher-level build system [1]

You cannot name a single use case where it is beneficial to know the mechanics of make when using CMake, much less the mechanics of Ninja.

[1] https://ninja-build.org/

Re: Using Make – writing less Makefile

#184
post #179

Earlier quoted context omitted.

> I'm a seasoned developer for the past 15-ish years and I haven't heard of ninja or gn before Then you also stopped learning about developments in your field 15 years ago. > I tried typing them in my command line (macos 12.4) and I would need to install them to use them. Ok? And? We don't pre-installed dev tools on consumer operating systems. You won't find valgrind or vcpkg either. > I was taught make in CS101 in c…

You seriously compare whatever this ninja thing is to valgrind with a straight face? There’s value in not overloading your cognitive capacity with the most recent fads, there’s enough serious tools and tech to learn.

> You seriously compare whatever this ninja thing is to valgrind with a straight face?

In so much as neither is pre-installed on a consumer operating system, yes, they are obviously equivalent.

> There’s value in not overloading your cognitive capacity with the most recent fads

Ninja has been the standard backend for CMake and other meta-generators for 11 years, it is hardly recent or a fad.

Moreover, you don't need to know anything about it, since it's a task-running backend format. You need to "know" it as much as you know the ELF object format or LLVM IR, your tools use it not you personally.

Re: Using Make – writing less Makefile

#185
post #181

Earlier quoted context omitted.

cmake generates makefiles (or ninja) so it doesn't replace them. It replaces autotools - it works out what features a system has and what build flags to enable and from a generic description of your program it generates makefiles or ninja.build. There's nothing fun whatsoever about fixing build problems with cmake - because you have to understand make/ninja AND cmake. It's slightly easier to understand than autotools…

> cmake generates makefiles (or ninja) so it doesn't replace them That make happens to be a possible target of CMake is irrelevant to this discussion, it replaces the usage of make. make becomes an implementation detail. No one should be writing Makefiles . You also shouldn't be using make as the underlying task runner but for a different set of reasons. > There's nothing fun whatsoever about fixing build problems wi…

When something doesn't build properly then you start needing to know the details and your logic about how make is an implementation detail is true of everything in the end - nobody cares how builds are done compared to the thing they build and often they don't care about that either except that it is needed by something which they need.

Re: Using Make – writing less Makefile

#186

Earlier quoted context omitted.

What’s the point of using another tool to manage your shell scripts though? Why not just use shell scripts

> What’s the point of using another tool to manage your shell scripts though? Why not just use shell scripts. When you create a Makefile, you're describing a dependency graph of what depends on what and the order tasks need to take to produce a particular set of digital artifacts--you're not writing shell scripts. Turns out there are all kinds of edge cases and foot guns that make handles for you that you'd otherwise…

> there's literally no build scenario it can't handle.

Well except this little case where some files or folders in your paths have spaces in them...

Re: Using Make – writing less Makefile

#187
post #164
post #146

Earlier quoted context omitted.

This? https://manpages.org/git-restore-mtime

Sure. Are you trying to imply the existence of a manpage means something ubiquitous?

I was wondering if “got-restore-mtime" was a typo or a cleverly named similar project to “git-restore-mtime".

Re: Using Make – writing less Makefile

#188
post #185

Earlier quoted context omitted.

> cmake generates makefiles (or ninja) so it doesn't replace them That make happens to be a possible target of CMake is irrelevant to this discussion, it replaces the usage of make. make becomes an implementation detail. No one should be writing Makefiles . You also shouldn't be using make as the underlying task runner but for a different set of reasons. > There's nothing fun whatsoever about fixing build problems wi…

When something doesn't build properly then you start needing to know the details and your logic about how make is an implementation detail is true of everything in the end - nobody cares how builds are done compared to the thing they build and often they don't care about that either except that it is needed by something which they need.

> When something doesn't build properly then you start needing to know the details and your logic

You would use compile_commands.json for this, which would show you the literal commands being invoked. What program is doing the invoking is 100% irrelevant. If the invoking program is what is breaking your build, your build is screwed beyond comprehension.

You don't need to know LLVM IR or the GCC intermediate representations, you don't need to know the internals of the ELF format, and you don't need to know make.

If you want to know these things more power to you, but don't insist that everyone should be writing LLVM IR because it's a more general building block than C++ or that anyone should use make for the same reason.

Re: Using Make – writing less Makefile

#189

Earlier quoted context omitted.

I don't see why there couldn't be (even today!) some statement like "require version XYZ", which Make could notice, which would enable new features and nicer syntax. Something like "editions" in Rust, though the idea is much older. For some reason, people prefer to add more layers on top of Make rather than improving the core language and tool. Maybe there's some good reason?

> rather than improving the core language and tool GNU Make has been steadily gaining new functions though. I've been reading the manual again recently and there were a few functions I did not recognize: let and intcmp. The new integer comparison function is particularly notable since people have gone to some rather incredible lengths to implement arithmetic in make: https://gmsl.jgc.org It's also possible to write n…

> arithmetic in make

Well that’s horrifying. What is the use case? Or is it just hackers gonna hack?

Re: Using Make – writing less Makefile

#190
post #110

I say this as someone with 20+ years of experience in C and C++: Using make is a huge waste of time in 2023 (and forward). Learning the intricacies of make actively blocks you from Getting Things Done. Yeah, make is kind of neat because it has this functional what_I_want : how_to_get_it syntax, but it doesn't actually work that way. It's a huge waste of time to try to get it working so unless you meet the following c…

If meson fits your project it's worth using it - it could turn into a straightjacket later but changing to something else isn't the end of the world if it cost little effort to implement it in the first place. As for trying to use a "modern" language to write scripts.......well if they're not declarative and don't understand dependencies then how can they be better? make is no paragon - it just contains solutions to…

> if they're not declarative and don't understand dependencies then how can they be better?

They are both a wash: you're spinning your gears trying to get a simple task done. My claim is that you might as well do it in python instead of wade through the cesspool of hidden rules or try to debug why your makefile silently fails. It's the same amount of time spent, you might as well check the date stamp in python and rebuild the source if it's newer than the output. They both suck, might as well suck in a modern language than trial by fire with make.

Post reply on HN