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

Be Aware of the Makefile Effect

blog.yossarian.net

Post reply on HN
Print view View original

311–320 of 347 posts

Re: Be Aware of the Makefile Effect

#311

Post by imtringued »

adrian_b wrote: post #79
mianos wrote: post #29

I have an alternate theory: about 10% of developers can actually start something from scratch because they truly understand how things work (not that they always do it, but they could if needed). Another 40% can get the daily job done by copying and pasting code from local sources, Stack Overflow, GitHub, or an LLM—while kinda knowing what’s going on. That leaves 50% who don’t really know much beyond a few LeetCode p…

Actually it is trivial to write a very simple Makefile for a 10,000 file project, despite the fact that almost all Makefiles that I have ever seen in open-source projects are ridiculously complicated, far more complicated than a good Makefile would be. In my opinion, it is a mistake almost always when you see in a Makefile an individual rule for making a single file. Normally, there should be only generic building ru…

Sure, but this will require you to know how to tell the compiler to generate your Makefile header dependencies and if you end up making a mistake, this will cause silent failures.

Re: Be Aware of the Makefile Effect

#312

Post by imtringued »

jandrese wrote: post #273
Quekid5 wrote: post #244

Earlier quoted context omitted.

They are simple but very often wrong . It's surprisingly hard to write Makefiles that will actually do the right thing under anything other than "build from scratch" scenarios. (No, I'm not joking. The very existence of the idea of "make clean" is the smoking gun.)

I disagree, but I think once a project gets beyond a certain level of complexity you may need to move beyond make. For simple projects though I usually do something like: CC=clang MODULES=gtk+-3.0 json-glib-1.0 CFLAGS=-Wall -pedantic --std=gnu17 `pkg-config --cflags $(MODULES)` LDLIBS=`pkg-config --libs $(MODULES)` HEADERS=*.h EXE=app ALL: $(EXE) $(EXE): application.o jsonstuff.o otherstuff.o application.o: applicati…

Makefile Effect in action...

Re: Be Aware of the Makefile Effect

#313

Post by imtringued »

rini17 wrote: post #178
jcarrano wrote: post #120

I wouldn't say this is necessarily a bad thing. I wrote my first version of a Makefile with automatic dependencies and out-of-tree builds 10+ years ago and I have been copying and improving it since. I do try to remove unneeded stuff when possible. The advantage is that one can go in and modify any aspect of build process easily, provided one takes care to remove cruft so that the Makefile does not become huge. This…

Can you imagine the makefile was made by someone else and you are now suddenly confronted with the result of 10 years of tuning.

I would let the expert do his job and I do mine.

Re: Be Aware of the Makefile Effect

#314

Post by kragen »

moregrist wrote: post #297
kragen wrote: post #171

Earlier quoted context omitted.

I agree. And there's no infallible algorithm. I think there are some good heuristics, though: - invest more of your time in learning more about the things you are currently finding useful than in things that sound like they could potentially be useful - invest more of your time in learning skills that have been useful for a long time (C, Make) than in skills of more recent vintage (MobX, Kubernetes), because of the L…

> invest your time in learning to use free software (FreeCAD, Godot, Postgres) rather than proprietary software (SolidWorks, Unity, Oracle), because sooner or later you will lose access to the proprietary stuff. The think you have a solid point with Postgres v Oracle and I haven’t followed game dev in a while, but your FreeCAD recommendation is so far from industry standard that I don’t think it’s good advice. If you…

You could have said the same thing about Postgres vs. Oracle 30 years ago. But it's true that these heuristics are not always in agreement.

Re: Be Aware of the Makefile Effect

#315

Post by Terr_ »

gjadi wrote: post #286
Terr_ wrote: post #274

Earlier quoted context omitted.

Hmm, I wonder what's the best way™ to, er "locally backup" those files, in such a way that no git-clean invocation will remove them without promoting. All I can think of are things like periodically copying them to another folder, or give them a different ownership needed for edit/delete, etc. Unless there's some kind of .gitpreserve feature...

You can have locally ignores files in .git/info/exclude IIRC.

I know there are local-only git settings, but AFAIK ignore-status won't protect files from being removed/overwritten by all possible git commands, it just means they won't be accidentally staged/committed.

Re: Be Aware of the Makefile Effect

#316

Post by computerfriend »

imtringued wrote: post #310
ajross wrote: post #160

Earlier quoted context omitted.

To be clear: I'm not suggesting a time machine, and I'm not listing any particular set of skills everyone must have. I'm saying that excusing the lack of core job skills by citing immediate time pressure is a smell. It tells me that that someone probably won't ever learn weird stuff. And in software development, people who don't learn weird stuff end up in that 50% bucket posited upthread.

You don't seem to understand that make is not a core skill. In an ideal world build tools would just work and people wouldn't have to think about them at all.

Someone has to write the makefile.

Re: Be Aware of the Makefile Effect

#317

Post by magic_smoke_ee »

Scubabear68 wrote: post #127

The best term for this is Cargo Cult Development. Cargo Cults arose in the Pacific during World War II, where native islanders would see miraculous planes bringing food, alcohol and goods to the islands and then vanishing into the blue. The islanders copied what they saw the soldiers doing, praying that their bamboo planes and coconut gadgets would impress the gods and restart the flow of cargo to the area. The issue…

An engineer should learn first principles and master the tool rather than dancing around it or reach immediately for replacing it with something else. This is why the "replacement" tool "just" is fundamentally terrible because it doesn't do dependency checking and optimizes for the wrong things. Instant loss of efficiency throwing away the power and simplicity of makefiles (GNU extensions often needed).

Instead, (GNU or vanilla) makefiles are ideals for very simple, portable projects. Make is everywhere.

For anything complicated, a proper build system that doesn't use autotools like cmake or bazel.

Re: Be Aware of the Makefile Effect

#318

Post by computerfriend »

rixed wrote: post #290
mauvehaus wrote: post #251

Earlier quoted context omitted.

The idea that git offers a 'clean' command was revelatory to me. Your build system probably shouldn't need to know how to restore your environment to a clean state because your source control should already know what a clean state is . That's sort essential to serving its purpose, after all. I haven't yet run into a scenario where there was a clean task that couldn't be accomplished by using flags to git clean, usual…

make clean is supposed to clean the intermediary files only but keep the actual build targets (typically what you want to install)

You might want .INTERMEDIATE in that case.

Re: Be Aware of the Makefile Effect

#319

Post by stefr- »

rednafi wrote: post #152

This also happens with tools you have to use but don’t get much payoff from—like internal tooling. At work, we have a shitty in-house feature flag service. It breaks all the time and is super finicky. Learning it properly doesn’t really help me, so I mostly copy and paste my way through it. Another example is jq. I use it occasionally, and ChatGPT handles the syntax pretty well. For me, learning it properly just isn’…

> Another example is jq. I use it occasionally, and ChatGPT handles the syntax pretty well. For me, learning it properly just isn’t worth the time or effort.

This resonates with me, I was in exactly the same position when I needed to do something with `kubectl` JSON output - just ask ChatGPT because I couldn't be bothered to learn the unintuitive syntax.

Interestingly I _can_ blame the tool, because I started using Nushell[1] which has built-in JSON manipulation that provides a MUCH simpler syntax, and I have learnt this properly because it was that easy.

1: https://www.nushell.sh/

Post reply on HN