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

An opinionated approach to GNU Make

tech.davis-hansson.com

Post reply on HN
Print view View original

181–190 of 195 posts

Re: An opinionated approach to GNU Make

#181

Post by chlorion »

jchw wrote: post #147
hedora wrote: post #133

Earlier quoted context omitted.

This is a sadly common corrolarry to "those who do not understand make are destined to reimplement it poorly". I strongly suggest spending an afternoon with "recursive make considered harmful" and the gnu make manual. I've never encountered a cmake proponent that can add trivial functionality to a cmake build in less time than it took me to learn make. I can usually port cmake builds to make in less time than such pe…

I have one question to ask you. How do I do this in Make: find_package(OpenGL) target_link_library(app OpenGL::OpenGL) Goals: - Support Windows, macOS, *NIX like - Compile with either MinGW or MSVC on Windows - Decent error output if GL headers are not found This SHOULD be possible. All we are doing here is calling the compiler with a fairly easy to derive set of options. Yet, in Make, there is no ideal way to abstra…

If you are targeting a GNU/Linux system and possibly other Unix like systems you can use pkg-config for this. All of the mainstream Linux distros support and use pkg-config, but I'm less sure about the BSD systems and MacOS since I've never used those before but from what I gather it should work for them too. Most Windows users probably don't have pkg-config installed but I also am not familiar with Windows.

Anyways if you are targeting platforms that support it, pkg-config will automatically generate the required flags for you, you can append them to a variable however you like, and later pass that variable to the compiler and linker.

You can try this out in a shell session if you are curious, try running:

    pkg-config gl --cflags --libs
You can see what libraries it knows about by running:

    pkg-config --list-all
Even when not using make directly a lot of build systems will be using pkg-config "under the hood"! Cmake is an exception here and has it's own way of doing this, but you can configure it to use what you want.

Just to be clear I am not saying makefiles are good or bad or what you should use, I just wanted to mention pkg-config because it's pretty cool and useful to know about.

The real answer to your question is to just use cmake I think!

Re: An opinionated approach to GNU Make

#182

Post by admax88qqq »

jlg23 wrote: post #156
admax88qqq wrote: post #151

Earlier quoted context omitted.

> GNUMake >= a specific version and on top bash instead of Posix SH It's such a shame that this is the attitude though. We're stuck with a make and shell frozen in time. Why even add new features to make/bash if nobody will run the new versions? Make is cool, but it's stagnated because people don't think we should rely on anything beyond POSIX

My development environment is FreeBSD, OpenBSD and Linux; I am deploying to non-linux unixes only. 99% of the patches I have to do to build systems are one-liners that explicitly spell out what syntactic sugar the newest feature of gmake/bash supported or that fixes what a linux-only developer considers to be "the standard" (and let's talk real, it's not only "linux-only" anymore, one has to say "this-specific-linux-…

Sure but do you pull in any other libraries or dependencies in your development that are newer than the 90s?

Why must the build system stick to POSIX when your libraries don't?

Re: An opinionated approach to GNU Make

#183

Post by jchw »

chlorion wrote: post #181
jchw wrote: post #147

Earlier quoted context omitted.

I have one question to ask you. How do I do this in Make: find_package(OpenGL) target_link_library(app OpenGL::OpenGL) Goals: - Support Windows, macOS, *NIX like - Compile with either MinGW or MSVC on Windows - Decent error output if GL headers are not found This SHOULD be possible. All we are doing here is calling the compiler with a fairly easy to derive set of options. Yet, in Make, there is no ideal way to abstra…

If you are targeting a GNU/Linux system and possibly other Unix like systems you can use pkg-config for this. All of the mainstream Linux distros support and use pkg-config, but I'm less sure about the BSD systems and MacOS since I've never used those before but from what I gather it should work for them too. Most Windows users probably don't have pkg-config installed but I also am not familiar with Windows. Anyways…

This is basically the best way I've seen to do this with pure Make, though I don't think it will work on macOS or even MSYS2 because even if you install pkg-config I don't think anything will provide definitions for OpenGL. (That's part of the reason I picked it; OpenGL is a really annoying edge case, since every platform went about it a little differently, and yet it is a common thing to need to link to.)

Re: An opinionated approach to GNU Make

#184

Post by penguin_booze »

I've been using make for a while now, but have never seen the $(@D) variant for target. I didn't know about .RECIPEPREFIX, either. Does anyone know if these were additions in the recent versions of make?

I could only find release notes in the mailing list [0]. Initial searches didn't turn up anything.

[0]: https://lists.gnu.org/archive/cgi-bin/namazu.cgi?query=gnu+m...

Re: An opinionated approach to GNU Make

#185

Post by int_19h »

yjftsjthsd-h wrote: post #177
int_19h wrote: post #174

Earlier quoted context omitted.

In Python, if you save your file with tabs as spaces, the code 1) still works, and 2) does the same thing it did before. Furthermore, it prohibits mixing tabs and spaces up in the same file, on the basis that it's impossible to reliably determine indentation levels then. So this isn't really a major issue with Python, unlike Make.

Sure, I'm happy to agree that the original design of make is kind of questionable. My point was that an editor which can handle telling you to not mix tabs and spaces in python should also be able to tell you to use tabs in a Makefile. Or, if you prefer, that if python can say "only tabs xor spaces" and be seen as reasonable, then make can say "only tabs" and be equally reasonable.

The editor doesn't need to do anything special to avoid mixing tabs and spaces in Python - quite the opposite, the simplest editors (the ones that either preserve or expand all tabs when you save, depending on the setting) will do.

Re: An opinionated approach to GNU Make

#186

Post by Oreb »

benreesman wrote: post #152
bee_rider wrote: post #139

Earlier quoted context omitted.

Tabs are obviously superior. If the tabs vs spaces argument must be had, and the correct option somehow loses, then we will have a much more annoying followup argument about how many spaces (I vote for three spaces and I will filibuster).

Since we’re doing this… ;) I’m actually coming around on really narrow conventions since tiny laptops started getting really good. I used to think 80-wide columns and 1-2 space indent was silly retro stuff in an era of modern displays. But on an M2 Air you can just barely get 80 + 80 side by side if you full screen SFMono at like 12-14pt. I’ll never sell my colleagues on it, but I’ve been playing around with setting…

I prefer around 80 characters per line maximum even on very large displays. More columns of text are always better, and I also find shorter lines easier to read.

Re: An opinionated approach to GNU Make

#187

Post by aldonius »

eropple wrote: post #31
jen20 wrote: post #23

Earlier quoted context omitted.

> And the Makefile is now non-portable. The article calls out GNU Make, so almost everything else in there is also non-portable.

Even beyond that I don't really understand the criticism. Like, I don't remember the last machine I had to do serious work on that didn't come with GNU Make either out of the box or added as part of some very basic bootstrapping scripts. (I don't know what a Mac comes with because my bootstrap for every new machine has coreutils in it and every project has a Brewfile with it too.) I definitely don't remember the last…

At least on my machine, it's a GNU Make... version 3.81.

I can only assume that's the last of the GPLv2 licensed ones. Classic Apple.

Re: An opinionated approach to GNU Make

#188

Post by chriswarbo »

bin_bash wrote: post #41
brabel wrote: post #39

Earlier quoted context omitted.

> I don't care if they've passed before and the files haven't changed. This is a common interjection from some people... which means you think that your tests are not deterministic, otherwise it would be completely pointless to run them again without inputs changing. I actually admit that from end-to-end tests, this is usually true despite our best efforts to the contrary... but for unit tests, I really think tests s…

> completely pointless to run them again without inputs changing What if I installed some dependency outside of my project? What if I'm trying to test performance with `time make test`? What if it failed due to a transitory error—or I'm simply trying to discover if it is transitory? What if I made a change to the way the tests are run in the Makefile or a different file not in ./src? Like running `npm install`? What…

> What if I installed some dependency outside of my project?

> What if I made a change to the way the tests are run in the Makefile or a different file not in ./src? Like running `npm install`?

> What if I want to set an environment variable or pass an argument to the test runner?

Those are all inputs. Unfortunately, Make isn't very good at tracking inputs (or outputs, for that matter: e.g. if we change an input back to some previous value, make will still rebuild rather than using the old result).

These days I find Nix to be a much more sane alternative to Make.

Re: An opinionated approach to GNU Make

#189

Post by chriswarbo »

nrclark wrote: post #25

This article has some questionable advice imo. SHELL := bash Bash is a much slower shell than Dash, which is why Debian and friends don't use it as /bin/sh. .ONESHELL mitigates the speed problem, but you could also just use the default shell and leave ONESHELL turned off. Use bash strict mode .... .SHELLFLAGS := -eu -o pipefail -c I wish people would stop cargo-culting the so-called "strict mode". The -e flag is only…

> Bash is a much slower shell than Dash, which is why Debian and friends don't use it as /bin/sh

Their advice is mostly about using a known interpreter, rather than 'vague POSIX hand-waving'; e.g. they end that section with:

> The key message here, of course, is to choose a specific shell. If you’d rather use ZSH, or Python or Node for that matter, set it to that. Pick a specific language so you can stop targeting a lowest common denominator

Your suggestion of Dash is compatible with that (as is any other particular shell interpreter).

An analogy would be running Selenium tests with particular browsers, rather than using /usr/bin/www-browser and trying to accomodate lynx, dillo, netsurf, ...

Re: An opinionated approach to GNU Make

#190

Post by padf »

jchw wrote: post #147
hedora wrote: post #133

Earlier quoted context omitted.

This is a sadly common corrolarry to "those who do not understand make are destined to reimplement it poorly". I strongly suggest spending an afternoon with "recursive make considered harmful" and the gnu make manual. I've never encountered a cmake proponent that can add trivial functionality to a cmake build in less time than it took me to learn make. I can usually port cmake builds to make in less time than such pe…

I have one question to ask you. How do I do this in Make: find_package(OpenGL) target_link_library(app OpenGL::OpenGL) Goals: - Support Windows, macOS, *NIX like - Compile with either MinGW or MSVC on Windows - Decent error output if GL headers are not found This SHOULD be possible. All we are doing here is calling the compiler with a fairly easy to derive set of options. Yet, in Make, there is no ideal way to abstra…

The trouble is not supporting all the different Operating systems/compilers, as make can do that. The issue is when the OpenGL library location varies, even on the same OS/compiler set.
Post reply on HN