The trouble with makefiles is that they're supposed to specify dependency relationships, but they're used as a procedural scripting language because the dependency system isn't very smart.
An opinionated approach to GNU Make
171–180 of 195 posts
Re: An opinionated approach to GNU Make
#172Earlier quoted context omitted.
Yet this has been settled in Makefiles for a long time: use tabs. OP only seeks to sit on a high horse about how tabs are bad and to divide an ecosystem which is already pretty consistent. I’m so tired of people insisting tabs are evil and that using them somehow makes you “wrong.”
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).
You can't meaningfully filibuster rustfmt / go fmt / Black / ... - that's the best thing about them.
Re: An opinionated approach to GNU Make
#173Earlier quoted context omitted.
It's high precision of a flawed view (in my opinion, of course) that should only be taken for what they are, an opinion. For any readers that want to learn make, look at the makefiles of big projects and see how they set things up. There's a huge difference of one person's opinions vs. a working system for a real world project.
Or RTFM. Make is ridiculously well documented. https://www.gnu.org/software/make/manual/make.html It's a peeve of mine that folks refuse to read the actual documentation for tools these days, preferring to wing it by copying other people's code.
People should be a little more forgiving. Even after reading emacs Manual thoroughly 3 times, I still managed to miss a ton of nuances and information. Same goes for make or other large old tools I guess.
Re: An opinionated approach to GNU Make
#174Earlier quoted context omitted.
Are you going to fix everyone else’s editor too? Software is a multiplayer game and eliminating a whole class of error that hinges on someone not noticing the difference between invisible characters in a diff is a huge win.
Are there any major editors that can't handle this? Given that python has a very similar kind of formatting I would assume any editor that a programmer is using today can handle it.
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.
Re: An opinionated approach to GNU Make
#175This is a really weird thread. It’s an opinionated blog post about relatively minor Makefile conventions with a clickbait title, which doesn’t look obviously self-submitted. And yet the thread is #1 and has 96 comments, of which like 92 are trashing the poor guy. Surely there is someone more worthy of an HN gang-tackle than this? It can’t be that slow of a news day.
[deleted]
Re: An opinionated approach to GNU Make
#176This is a really weird thread. It’s an opinionated blog post about relatively minor Makefile conventions with a clickbait title, which doesn’t look obviously self-submitted. And yet the thread is #1 and has 96 comments, of which like 92 are trashing the poor guy. Surely there is someone more worthy of an HN gang-tackle than this? It can’t be that slow of a news day.
It's triggering for some people to be told that they are wrong, even if the person who said it doesn't actually know them specifically, wasn't thinking about them as individuals when they wrote the blog, and has no idea that they exist. The idea that someone could be so presumptuous to assume that they had more make knowledge than everyone on the planet makes them very angry, because they are someone on the planet, s…
> It's triggering for some people to be told that they are wrong, even if the person who said it doesn't actually know them specifically, wasn't thinking about them as individuals when they wrote the blog, and has no idea that they exist.
...and, of course, when they're not actually wrong.
> No shit, buddy, I wrote it, who else's opinion would it be?
Okay, if OP can have an opinion that "Your Makefiles are wrong", then I can have an opinion that " Your article is wrong". Fair?
Re: An opinionated approach to GNU Make
#177Earlier quoted context omitted.
Are there any major editors that can't handle this? Given that python has a very similar kind of formatting I would assume any editor that a programmer is using today can handle it.
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.
Re: An opinionated approach to GNU Make
#178Earlier 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).
You can't meaningfully filibuster rustfmt / go fmt / Black / ... - that's the best thing about them.
I mean, this is mostly joking, of course if I was on a team I'd put forward my argument once and then comply with the conclusion the group makes, it is not really a big deal anyway.
Hopefully somebody wouldn't just apply an auto-formatter, that'd be quite rude!
Re: An opinionated approach to GNU Make
#179Earlier quoted context omitted.
Or RTFM. Make is ridiculously well documented. https://www.gnu.org/software/make/manual/make.html It's a peeve of mine that folks refuse to read the actual documentation for tools these days, preferring to wing it by copying other people's code.
People should be a little more forgiving. Even after reading emacs Manual thoroughly 3 times, I still managed to miss a ton of nuances and information. Same goes for make or other large old tools I guess.
Make is not emacs. Its nowhere in the same stratosphere as emacs other than being under the GNU umbrella.
And being forgiving of not understanding the docs requires someone to read the docs in the first place.
Re: An opinionated approach to GNU Make
#180Earlier 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…
You should either trust the OS to package GL, or vendor it yourself. If you trust your build environment, then -lGL is the right answer. If you do not, then vendoring libGL is the right answer. Both approaches are easy to achieve with make. find_package semantics are frankly weird: "maybe use the OS version, or override in nonstandard ways, or maybe download some version from somewhere and build it using some compile…
This is the perfect non-answer.
The question I asked is simple. CMake has an answer. Make has more questions.