An opinionated approach to GNU Make • Hacker News Board

Re: An opinionated approach to GNU Make

#191

Post by jchw » Mon, Aug 22, 2022, 6:11 PM UTC

padf wrote: post #190

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…

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.

It's kinda both. The problem is that it doesn't really make sense to do all of this work to configure the build directly in Make, so if you need any kind of expensive detection (like calling pkg-config or testing if some library function is available) it's best to do it in a configure script. Most projects don't have terribly special needs, so it would be both overkill (too much effort) and insufficient (not supporting enough use cases) to do a lot of custom configuration code. So most projects wind up using something like Autoconf, which has already done a ridiculous amount of work to work on almost everything, supporting important use cases like out-of-tree builds and cross-compilation, but even then it has some unfortunate limitations.

As much as I don't think CMake is elegant or perfect by any means, CMake is nice because it does work, and there generally is a proper way to do things even if it's not always intuitive. And for how bad it can be, honestly, it's much less of a pain in my opinion than dealing with autotools, for many reasons. Just to be concrete about it, one thing I find really painful with autotools is trying to find the exact combination of versions that will actually work with a given project... With CMake, usually newer versions are always OK, and there's a decent focus on both backwards compatibility as well as explicitly declaring the required CMake version. There's more, but it's probably not worth getting into, as I don't think most people defend autotools as being particularly nice to use.

Some projects, like the Linux kernel, can definitely get away with Make and custom configuration, since a lot of higher-level general purpose tools are not really well-suited for their needs anyways. I feel like most projects (somewhere on the order of >99% of them) are not really in this boat.

Re: An opinionated approach to GNU Make

#192

Post by agumonkey » Tue, Aug 23, 2022, 4:32 PM UTC

falcolas wrote: post #179

agumonkey wrote: post #173

Earlier quoted context omitted.

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.

I'm sorry but it's the same pedagogical limit that gets hit. You read 50% of the manual, integrate 20% of that.

Most of the time I needed two or three passes in different context to start to really grasp a tool domain.

Re: An opinionated approach to GNU Make

#193

Post by WesolyKubeczek » Wed, Aug 24, 2022, 11:42 AM UTC

gpderetta wrote: post #165

WesolyKubeczek wrote: post #105

Earlier quoted context omitted.

Make can do more than compile a bunch of C files. If you can express your goals and dependencies as files with meaningful creation timestamps, it can be a potent task executor that can also skip over steps if they are already done. Also, your CMake generates Makefiles, so... CMake and meson/ninja, though, seem to be pretty much tuned to compiling C-shaped things, although I’d like to see them (ab)used for other thing…

Incidentally, is there such a thing as a distributed Make that can run and check the dependencies across machines? Of course Make + ssh and a distributed FS gets you there, but you don't always have a distributed FS especially across continents.

Yes there is, for Solaris at least: https://docs.oracle.com/cd/E77782_01/html/E77803/dmake-1.htm...

Trigger warning: the thing is mature enough to speak about rsh(1) seriously.

IllumOS has a "dmake" command, but as far as I've read its man page, it's not distributed across hosts and likely exists for compatibility.

It is said that dmake is licensed under CDDL, but it will take a more patient soul to get to the sources. Oracle Developer Studio can be downloaded and run, so I presume you can toy with it: https://www.oracle.com/tools/developerstudio/downloads/devel...

CloudBees build a thing to vendor-lock your development workflow in, and they have a thing called ElectricAccelerator. It's vastly more complicated, and from I gather, hosted. But they say it can ingest "most" GNU Makefiles and distribute tasks across worker nodes.

Re: An opinionated approach to GNU Make

#194

Post by spicybright » Mon, Aug 29, 2022, 2:23 PM UTC

pessimizer wrote: post #114

spicybright wrote: post #93

Earlier 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.

Any specific criticism about any points made in the article, or just general shade and a nonspecific recommendation?

Well, I think my point of learning from how people actually use make in the real world to be perfectly valid for learning, as is learning any kind of language/tool.

But here's my criticisms:

> Instead, ask make to use > as the block character, by adding this at the top of your makefile:

Changing this is like replacing java curly braces with square brackets because it's easier to type. A good developer should be able to cope with different stylistic choices to match the existing code without strain IMO

Maybe if it was a greenfield project it's ok, but the article doesn't say either way.

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

I disagree with using ZSH as it adds another dependency and shell to learn to build your project. This introduces more ramp up in knowledge, but also something build systems will have to pull in.

The vast majority of steps end up as simple unix commands and program calling with specific flags in practice.

Python is a maybe if that's the only language you're working with. Otherwise anything but simple function calls is better served by an external file. Even a simple module function call becomes clunky on one line.

This is an interesting idea worth exploring in general, though.

> Make has a bunch of cryptic magic variables that refer to things like the targets and prerequisites of rules. I mostly think these should be avoided, because they are hard to read.

See point 1. This is like choosing to not use regex because the symbols are confusing.

~

The rest of the article has good stuff in it though, esp. the file structure and bash flags. The rest is just questionable opinion and has little impact to a good makefile.

Can you give some arguments against what I typed above?

Re: An opinionated approach to GNU Make

#195

Post by raggi » Wed, Aug 31, 2022, 3:20 AM UTC

bin_bash wrote: post #82

raggi wrote: post #70

if you're building C please try to use the built-in rules. I often come across reimplementations that miss or disorder one of the flag sets and it becomes a pain when porting or integrating. General reminder: you don't even necessarily need a make file to build C: ~ % echo 'void main(){printf("hello");}' > example.c ~ % make example cc example.c -o example ... 2 warnings generated. ~ % ./example hello%

This is really cool! I've always worked in interpreted code so this isn't that useful to me but I'm surprised that it exists. I tried it myself though and it complains about not including stdio.h and wanting `int main` instead of `void main`. Though of course I still get your point.

Yes, I left out the warnings for brevity. It's a bit of a pain to do all the includes in a one-liner :)

What this does allow you to do though, is also do things like:

  make CFLAGS=-DFOO LDFLAGS=-lfoo example