The GnuWin32 port of Make [1] is version 3.81. I've used it when I needed GNU Make on Windows. I know there are other ways to get newer versions of Make on Windows, but the GnuWin32 port is simple, standalone, and it still works despite its age...
mostly i use make for small tasks that will also run on other people's computers -- not worth the hassle to ask them to install a newer make just for that.
even for myself, as much as possible i try to just rely on what's built-in, if reasonable. time is precious!
the mac is shitty in a million ways, but it's still by far the least shitty, for me, out of the windows, linux, mac trinity. tho at this point it's been years since i've spent much time non-mac, so maybe the situation has improved -- i'll probably give it another go once asahi linux matures (or its m1 support is adopted by other distros).
(also the arm mac notebook hardware is just insanely good, imo.)
[3] Install GNU Coreutils (just type “brew install coreutils” in the terminal)
Command Line Tools is the package that contains the compiler (clang), Git and all the expected development tools.
Obviously, depending on what kind of development you’re doing, you’ll install the runtime packages and utilities you would have installed on Linux, BSD or Windows anyway.
If you’re a web developer, for example, you'll probably need to install NodeJS, and a bunch of bundlers, linters, pre/post processors, task runners (Gulp, Grunt, Webpack, Parcel, etc.).
No matter which platform you’re on, nobody loves their default terminal emulator, so you’ll need to install iTerm2, Alacrity, Kitty or my new favorite, WezTerm.
Oh and the editor! macOS comes with Vim and Emacs, but you’ll want your favorite distribution/version/fork. (If you’re into VS Code, you can brew install vscodium). Even if the bundled version is what you want, then there’s the plugins, extensions, packages you need. Again, regardless of platform.
The point is, no matter what platform you choose, you need to install a bunch of things to get going. macOS isn’t significantly worse in this regard.
Why did you bother to install Homebrew in step #2, though, if you are unwilling to then use it to install something as trivial as a newer version of make?
I’m using Make for years now but usually only for very basic things. I always feel like it can do much more.
Are there any good docs/books/articles about advanced usage of make?
> Of course, the manual itself is really very good!
I actually don't agree with this. It's really good as a "user guide", but it's not the best as a "reference manual". It does not always clearly define terms, it freely mixes technical terms and hand-waving language, the writing style tends toward an "expository prose" that makes it hard to find specific pieces of information. In general, it could do with some reorganization using the Diátaxis principles: https://diataxis.fr/
It does have pretty good indices, and the quick reference is very helpful. However the HTML version (can't speak for the others) needs a lot more anchors, to make it easy to cross-link to individual elements, rather than just to chapter headings.
Huh. I actually thought the manual was great, but you make excellent points that I happen to agree with.
I'm very comfortable with the manual now, when I need to look something up, but that's because I've spent years looking things up in it, so I have a fairly good idea where to find things. Even so, it's sometimes confusing, e.g. where to find the definition of automatic variables like `$@`, `$^` and the like? When I started learning Make I remember it being infuriatingly hard to find the entry about a topic of interest.
While the manual is great (as are most of GNU's major works!) compared to most of the software ecosystem [1], you're quite right that it can still improve a lot.
[1] It's kind of amazing how even a company like Apple can have some pretty underwhelming documentation, see today's post about ExtensionKit https://news.ycombinator.com/item?id=33409558
One thing that's helpful is to study how real-world projects use Make. Try to understand them, and look up pieces you're missing from the reference material. You'll probably end up having to dive into autotools, too, for some of it.
I'm a big fan of using a standalone Makefile to manage the build of a project rather than having the IDE do it by "magic." Makefiles can also be used to handle a lot of repetitive processes or tasks that have to happen in a certain order based on dependencies -- they aren't limited to running compilers.
If this wasn’t LWN, I’d call it “blogspam”, but I know LWN does this to have their own archive which they can link to. But this does not mean that there’s any good reason for anyone outside of LWN to use LWN’s copy of the announcement, unless the original link had gone stale or something.
LWN is not a general mailing list archive; AFAIK, LWN only archives the posts which they want to link to in an accompanying or related article. LWN does not, AFAIK, archive every post on, in this case, the info-gnu list.
> Previously each target in a explicit grouped target rule was considered individually: if the targets needed by the build were not out of date the recipe was not run even if other targets in the group were out of date. Now if any of the grouped targets are needed by the build, then if any of the grouped targets are out of date the recipe is run and all targets in the group are considered updated.
This is a welcome change! I always thought this was how Make worked anyway, until I tried it and it didn't. Unfortunately none of my coworkers using stock Make on their Macs can benefit, but I can also insist that they install v4.4 since they all have Homebrew already.
> .WAIT
What's a use case for this? Is the idea that you can use it for explicitly sequencing build order of dependencies, without making them actually dependent on each other? Why would you want that?
> let, intcmp
The Turing Tarpit grows... do we have a Scheme interpreter in Make yet?
> What's a use case for this? Is the idea that you can use it for explicitly sequencing build order of dependencies, without making them actually dependent on each other? Why would you want that?
A use-case that I've wanted this for for a long time is to have build phases. `make install` should build things if necessary; but it'd also be great to have it build everything before it installs anything.
> What's a use case for this? Is the idea that you can use it for explicitly sequencing build order of dependencies, without making them actually dependent on each other? Why would you want that?
I tried reading that part of the changelog a bunch of times but my brain is having a difficult time parsing it... Could someone please give us an example of what's that problem with the grouped targets?
57 comments
[ 2.9 ms ] story [ 116 ms ] threadDoes that include only Xenix proper (last release '89), or later SCO derivatives as well (SCO UNIX/OpenServer)? Asking purely out of curiosity.
Even Debian 9 had Make 4.1. You either have a very old OS or are keeping it around for some reason.
[1]: https://gnuwin32.sourceforge.net/packages/make.htm
I assume GP knows about Cygwin and elects not to use it.
unfortunate situation.
I'll never understand why other developers like Macs. I had to use one for work and it was horrible. I can't imagine paying 2 grand for that!
even for myself, as much as possible i try to just rely on what's built-in, if reasonable. time is precious!
the mac is shitty in a million ways, but it's still by far the least shitty, for me, out of the windows, linux, mac trinity. tho at this point it's been years since i've spent much time non-mac, so maybe the situation has improved -- i'll probably give it another go once asahi linux matures (or its m1 support is adopted by other distros).
(also the arm mac notebook hardware is just insanely good, imo.)
If you’re not developing native apps for any of Apple’s platforms, all you need (for starters)
[1] Command Line Tools (just type "xcode-select --install” in the terminal)
[2] Install Homebrew (https://brew.sh)
[3] Install GNU Coreutils (just type “brew install coreutils” in the terminal)
Command Line Tools is the package that contains the compiler (clang), Git and all the expected development tools.
Obviously, depending on what kind of development you’re doing, you’ll install the runtime packages and utilities you would have installed on Linux, BSD or Windows anyway.
If you’re a web developer, for example, you'll probably need to install NodeJS, and a bunch of bundlers, linters, pre/post processors, task runners (Gulp, Grunt, Webpack, Parcel, etc.).
No matter which platform you’re on, nobody loves their default terminal emulator, so you’ll need to install iTerm2, Alacrity, Kitty or my new favorite, WezTerm.
Oh and the editor! macOS comes with Vim and Emacs, but you’ll want your favorite distribution/version/fork. (If you’re into VS Code, you can brew install vscodium). Even if the bundled version is what you want, then there’s the plugins, extensions, packages you need. Again, regardless of platform.
The point is, no matter what platform you choose, you need to install a bunch of things to get going. macOS isn’t significantly worse in this regard.
No need to go back over the GPLv2 vs. GPLv3 situation with macOS. There are dozens of threads on HN about it.
However, it’s easy to solve in any number of ways; I’d recommend installing Homebrew [1] and using it to install make.
BTW, Homebrew has make 4.4 ready to go; I just installed it [2].
[1]: https://brew.sh
[2]: https://formulae.brew.sh/formula/make#default
I did not just check one of our servers.
:(
In particular, 3.82 changed how precedence between pattern rules works.
https://www.oreilly.com/library/view/managing-projects-with/...
O'Reilly is free via my public library. Yours might have the same
https://nostarch.com/gnumake
I just noticed he did some screencasts that make up a course:
https://cloudflare.tv/shows/the-gnu-make-course
And here's links to a bunch of blog posts, from which I learned a lot:
https://blog.jgc.org/2013/02/updated-list-of-my-gnu-make-art...
Of course, the manual itself is really very good!
I actually don't agree with this. It's really good as a "user guide", but it's not the best as a "reference manual". It does not always clearly define terms, it freely mixes technical terms and hand-waving language, the writing style tends toward an "expository prose" that makes it hard to find specific pieces of information. In general, it could do with some reorganization using the Diátaxis principles: https://diataxis.fr/
It does have pretty good indices, and the quick reference is very helpful. However the HTML version (can't speak for the others) needs a lot more anchors, to make it easy to cross-link to individual elements, rather than just to chapter headings.
I'm very comfortable with the manual now, when I need to look something up, but that's because I've spent years looking things up in it, so I have a fairly good idea where to find things. Even so, it's sometimes confusing, e.g. where to find the definition of automatic variables like `$@`, `$^` and the like? When I started learning Make I remember it being infuriatingly hard to find the entry about a topic of interest.
While the manual is great (as are most of GNU's major works!) compared to most of the software ecosystem [1], you're quite right that it can still improve a lot.
[1] It's kind of amazing how even a company like Apple can have some pretty underwhelming documentation, see today's post about ExtensionKit https://news.ycombinator.com/item?id=33409558
[small plug] I've just done a presentation at $Work saying just that:
> By using Makefiles in your repos, you document and automate common "build" tasks.[1]
[1]: https://jiby.tech/presentation/makefiles/makefiles
My last workplace was very Makefile heavy and I used that as an excuse to read it. 10/10, would recommend/do it again.
Well, I'll use it to compile make on elf/linux.
If this wasn’t LWN, I’d call it “blogspam”, but I know LWN does this to have their own archive which they can link to. But this does not mean that there’s any good reason for anyone outside of LWN to use LWN’s copy of the announcement, unless the original link had gone stale or something.
Heck, most LKML posts get posted as lkml.iu.edu or lwn.net; rather than lore.kernel.org or lkml.org.
> Previously each target in a explicit grouped target rule was considered individually: if the targets needed by the build were not out of date the recipe was not run even if other targets in the group were out of date. Now if any of the grouped targets are needed by the build, then if any of the grouped targets are out of date the recipe is run and all targets in the group are considered updated.
This is a welcome change! I always thought this was how Make worked anyway, until I tried it and it didn't. Unfortunately none of my coworkers using stock Make on their Macs can benefit, but I can also insist that they install v4.4 since they all have Homebrew already.
> .WAIT
What's a use case for this? Is the idea that you can use it for explicitly sequencing build order of dependencies, without making them actually dependent on each other? Why would you want that?
> let, intcmp
The Turing Tarpit grows... do we have a Scheme interpreter in Make yet?
> What's a use case for this? Is the idea that you can use it for explicitly sequencing build order of dependencies, without making them actually dependent on each other? Why would you want that?
A use-case that I've wanted this for for a long time is to have build phases. `make install` should build things if necessary; but it'd also be great to have it build everything before it installs anything.
To introduce concurrency unsafety by deadlocks.