Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using Make – writing less Makefile

text.causal.agency

Post reply on HN
Print view View original

191–200 of 200 posts

Re: Using Make – writing less Makefile

#191

Post by nrclark »

dmd wrote: post #189
matheusmoreira wrote: post #165

Earlier quoted context omitted.

> 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?

Incrementing a counter would be one example. Like maybe you want to produce file-00.txt through file-99.txt.

Re: Using Make – writing less Makefile

#192

Post by gregwebs »

KajMagnus wrote: post #104
nine_k wrote: post #91

Earlier quoted context omitted.

No, no. Make's principal purpose is to put a set of files into a desired state. It can "make" a particular file by invoking a dependent graph of commands that produce that file from other files. It checks timestamps and only run steps where the resulting files are older than some of the (transitive) source files. You can invoke it by naming a named rule, not a file, but the logic will remain. If this is not what you…

I also don't like Make for running commands. I was using Make for running commands, but it interprets all command line parameters as build targets, which was annoying. And Bash scripts in Makefiles aren't type safe, became messy. Nowadays I use Make only for building. And Deno + Typescript instead, for running commands & scripts. (Hadn't heard about Just — the scrips aren't type safe though?)

depends on how you define type-safe. Even in TypeScript you are still executing strings when running commands. You can turn those strings into variables and share them as a form of type safety- the type check will fail if you mis-type the variable name. Just supports that- you will get an error if a variable that is being inserted doesn't actually exist. The error will occur at startup before usage or can be checked ahead of time with just --check --fmt. So for quick usage there's not much benefit to TS, but over time in TS you could build up type safe interfaces to commands and obviously if you want to run TS scripts instead of shell scripts that's going to have more opportunities for strong typing then invoking TS from just.

Re: Using Make – writing less Makefile

#193

Post by dagmx »

angra_mainyu wrote: post #175
dagmx wrote: post #89

Earlier quoted context omitted.

I’m not specifically advocating for CMake , though it is my preference for many reasons like faster uptake of multiple platform and compiler features. I was merely pushing back on the person perplexing on why people don’t just use Make.

Why cmake and not meson?

Covered in my statement above but to expand a bit:

meson lags behind for supporting new features like different languages (Swift, ObjC etc), Xcode/msvc updates, IDE integration (CLion is amazing), build outputs like frameworks.

basically, Mesons better ergonomics lose out to practicality for my use cases. To get it do what I need, I’d be making my own meta system around it.

Re: Using Make – writing less Makefile

#194

Post by maccard »

stouset wrote: post #140
maccard wrote: post #138

Earlier quoted context omitted.

I think this is a great example of tools being stuck in the 90's, actually. Make should be parallel by default. I get it, I do. I know there's all sorts of legacy reasons, but my 4k resolution screen with 12GB vram and 32 cores still runs make build serially, outpitx to an 80x24 window and is bottlenecked down by stdout flushing, all because we can't change defaults.

And annoyingly, I don’t think there’s a way to tell `make` that a particular `Makefile` should be built with multiple threads by default. So you have to specify `-j` every time.

Yep. If it was opt-in in a per-makefile way, it would be ok (or preferably opt-out).

I think cmake got this absolutely right, fwiw. You define the version of cmake you're writing against, and they go to great pains to ensure that they preserve behaviour even in newer versions of cmake. As an example, we could have a special variable:

    make_ver = 4.5
And even running with a future version of make the behaviour would be that of 4.5. if it's not present, it defaults to the latest version before the versions were introduced.

This would let make do things like accept spaces instead of tabs, be parallel by default, etc in future versions while presenting old behaviour.

Re: Using Make – writing less Makefile

#195

Post by Brian_K_White »

dmd wrote: post #189
matheusmoreira wrote: post #165

Earlier quoted context omitted.

> 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?

idk about anyone else but I have auto incrementing build numbers in several makefiles

That would seem to be the most obvious and trivial example and I just assume that there must be countless others without having to actually see them and agree that they are valid.

Wait, how could I forget the other most obvious example, comparing version numbers of requirements/dependencies?

The Vala preprocessor can't compare numbers and so I have to implement "if libfoo < x then add -D OLDFOO" outside in the makefile and can only have boolean #if OLDFOO in the code. (libs don't always provide good enough equivalents, maybe only provides a numerical value that you are assumed to be able to compare, or maybe provides nothing at all, or does provide a set of booleans intended to be used for this but they aren't granular enough, etc)

Re: Using Make – writing less Makefile

#196

Post by Brian_K_White »

m463 wrote: post #141
heads wrote: post #108

Make is the grilling of the hacker world. You just want to light up some quality lumpwood charcoal and get a nice smokey crust on some steaks, cook up some hamburgers, and crisp up some chicken for your guests over the course of an afternoon… …but oh no there is a constant stream of inquisitive folk coming over, beer in hand, suggesting cool adjustments / hacks / “improvements” to your setup. With grilling it’s actua…

make is very useful. The idea that things depend on each other and are built as a hierarchy is important. But it is the opposite of beauty, or elegance, or organization. Honestly all the millions of man months that have gone into writing makefiles should have gone into making make more usable. for example: all the implicit rules in this article? Nobody¹ uses them, they should just be explicit. You shold explicitly di…

Agree on implicit behavior.

Actually I think it's fine for the implicit automatic features to exist, I just think no one should use them in most cases.

It's fine for a tool to try to be as magic as possible, as an optional thing you can do whaen you decide you want. And for practically any makefile that you are bothering to actually write into a file that you are keeping and running again tomorrow, and giving to someone else to run some other day on some other machine... everything should be explicit. Just like the projects code, it's documentation as much as function, and no part of either the documentation or the function should be left unexplained and undetermined.

But that's a seperate issue from the tool having the ability. I think it's not a tools job to tell me what I want and why and what is and is not valid. If make never had the magic features, I would not miss them feel any need to invest in adding them, but if they are there anyway somehow, I also don't see any reason to remove them or create a new tool just to have something that doesn't have them.

I should be free to write a short super convenient fully magic 3-line makefile that just says "do the likely thing with whatever is in this directory", and at the same time, no project should ever have that as their real makefile. Both stances are valid at the same time, I think.

Re: Using Make – writing less Makefile

#197

Post by Brian_K_White »

alwillis wrote: post #172
m463 wrote: post #141

Earlier quoted context omitted.

make is very useful. The idea that things depend on each other and are built as a hierarchy is important. But it is the opposite of beauty, or elegance, or organization. Honestly all the millions of man months that have gone into writing makefiles should have gone into making make more usable. for example: all the implicit rules in this article? Nobody¹ uses them, they should just be explicit. You shold explicitly di…

All I can say about these critiques: I learned make a few years ago and it wasn't nearly as bad as it was made out to be. As someone who cares about the aesthetics of code, I thought I would hate using make but I ended up enjoying writing modern makefiles. When make was created back in the day, I get why certain choices were made, like with virtually all Unix tools of that era. But we don't have to use them in the sa…

The beauties of make are:

* It actually does the complicated job correctly, or can, it provides the means to. A lot of things that claim to be "new better make" are simpler by being simply incomplete and/or internally more magic and less correct and less deterministic.

* Single simple binary. No freaking python or ruby of just a certain vintage and 500 modules but maybe not the system ones or maybe only the system ones...

* Always available everywhere, not just in the middle of the bell curve of modern and popular systems, and will be tomorrow exactly the same as yesterday. Deviations like gmake vs bsdmake are essentially trivial and don't really break anything or present any real problem. IE: portable across both space and time in all directions of all dimensions.

Make is sane for the job it does. It's a great example of a correct use and application of a DSL.

And all those complaints are still true. I address them by:

* Simply adopt a habit or discipline to voluntarily avoid the implicit features. Don't use globbing either. Just don't use those features that are unwise. They are still there, but you don't have to invoke them.

* Just suck it up and deal with the tabs and whitespace and line-continuation and quirks like how each line of shell in a target is a new shell environment unless you build the annoying long single command, capturing exit values so they don't reach the parent make process and get treated as an error, etc. Whatever. To me that's all just normal shell scripting requirements in any context, make not especially different from cron or cgi or other. Rather that than passing around powershell objects or something.

Could be better but ninja or whatever is not the answer to those minor annoyances.

Re: Using Make – writing less Makefile

#198

Post by nocombination »

dagmx wrote: post #193
angra_mainyu wrote: post #175

Earlier quoted context omitted.

Why cmake and not meson?

Covered in my statement above but to expand a bit: meson lags behind for supporting new features like different languages (Swift, ObjC etc), Xcode/msvc updates, IDE integration (CLion is amazing), build outputs like frameworks. basically, Mesons better ergonomics lose out to practicality for my use cases. To get it do what I need, I’d be making my own meta system around it.

I recommend taking a look at Autotools—if anything for historical context. It quickly becomes apparent that many features in CMake (and likely meson—no experience there myself)—are derived from some functionality in Autotools. It also helps one appreciate the package maintainers role in the software development lifecycle, as many of the GNU coding standards have influenced software packaging/distribution—be it RPM, Deb, Pacman, etc.

While there is certainly value in using CMake (as so many projects have chosen it as their build system)—it also becomes a sort of cautionary tale whence projects try to reinvent the wheel to fix some deficiency, only to build a complex system with it's own set of deficiencies. Obviously, part of this is due to the fact that commercial entities (cough Microsoft) deviated from any sort of standards-based approach to building software.

But for every build-configuration system, Autotools seems to be the only one which dictates that a developer machine merely have POSIX tools installed. Nowadays, that's all the big players, considering that MSYS2 on Windows is better than ever. And it supports many languages to boot: C/C++, Objective C/C++, Go, Fortran, Erlang.

Re: Using Make – writing less Makefile

#199

Post by alwillis »

nickelpro wrote: post #117
t43562 wrote: post #103

Earlier quoted context omitted.

Make has few dependencies so it's a way to build an operating system up from ground 0. Any tool/language that wishes to be generally useful in an OS doesn't want to be built by something that is only available much further up the tree like python. So it gets used a lot and it's only a language for dependencies and rules. It doesn't do "project management". Its the simplicity of what it's trying to that saves it from…

> Any tool/language that wishes to be generally useful in an OS doesn't want to be built by something that is only available much further up the tree like python. This is a non-priority, an unreal use case. I can't build GCC without a functioning C++ compiler and a fairly sophisticated OS environment and that's fine. Real-world use cases for bootstrapping a build environment from rubbing two sticks together are so ex…

> We live in a world where for every language there are build tools that know far, far more about the needs of that language environment than make, and thus are far better suited.

Languages don't exist in a vacuum.

A big reason for the resurgence of make by developers is every language/environment comes with something new that tries to recreate make. They all have issues and limitations where make ends up being a better tool.

Also, when you need to deal with multiple languages in a project, these tools tend not to be that helpful.

As a web developer, there's been so many attempts to make tools like gulp [1], grunt [2], npm scripts [3], web pack [4], etc. and a dozen more, to do a part of what make has been doing for decades. And literally every 6–12 months, there's a new, hot tool that everyone gets excited about. It's just reinventing the wheel over and over.

Now that I've settled on make for web projects, it's no longer a concern.

I much rather describe my dependencies using make than JavaScript (ugh), which many of these tools use. Some tools fall out of favor; developers stop creating plugins or whatever for them. As a user of the tool, you can find yourself shit out of luck for your particular project or use case.

The beauty of make is it can handle the tasks of building a web site or web app using modern tools that didn't exist when it was created. As someone mentioned further up, make is eternal; it's not going anywhere.

[1]: https://gulpjs.com

[2]: https://gruntjs.com/

[3]: https://docs.npmjs.com/cli/v9/using-npm/scripts

[4]: https://webpack.js.org

Re: Using Make – writing less Makefile

#200

Post by t43562 »

gosub100 wrote: post #190
t43562 wrote: post #110

Earlier quoted context omitted.

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 re…

Oh, I think that's OFTEN true. When your build gets big though - when you're building multiple packages for example of which most are not yours - the benefits can start to become more worthwhile.

I currently work with people who think a huge build.sh is the way to go - so the build does a lot of unnecessary things just to be sure they are uptodate and it's slow. It's still not bad enough to kick up a fuss but it's going that way.

Post reply on HN