Live data from Hacker News

Be Aware of the Makefile Effect

blog.yossarian.net

341–347 of 347 posts

Re: Be Aware of the Makefile Effect

#341
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…

10 years ago people said the same about KiCAD and Blender :) No guarantee that FreeCAD will be the same - but you can be pretty confident it will never go away.

However, if the goal is to be a full time employee doing CAD, I would of course going with one of the most established tools. Potentially even get some certifications.

Re: Be Aware of the Makefile Effect

#342

Earlier quoted context omitted.

For a start, any suite that takes >X hours on a single node, especially compounded if you have a large team of developers. > At least as long as you're running your own code on your own hardware Assuming you keep a consistent env/OS across all nodes you will want to run said code. Which can be difficult, even just between two users on a single node. Not to mention the fact that a lot of (most?) code needs to (A) inte…

> For a start, any suite that takes >X hours on a single node, especially compounded if you have a large team of developers. If your testing suite takes several hours to run on a 256 core server, and this is something you want to run on every commit by every dev, then you have a problem with your testing suite. Running it on k8s is just slapping a bandaid on it. > Assuming you keep a consistent env/OS across all node…

Clusters and supercomputers are able to fully control the hardware & OS. environment modules are useful in that setting but do not solve OS differences, not to mention themselves need to be installed/maintained. lots of time developers do not work on your same cluster (say, for any open-source code) and environment differences can be significant.

I regularly use large clusters and even there docker/singularity are very helpful at times (very simple example, glibc requirements).

When you are talking about well-written code that only requires posix (and nothing beyond) and does not interface with hardware, etc. etc. then virtualization seems crazy.

Re: Be Aware of the Makefile Effect

#346
post #253
post #247

Earlier quoted context omitted.

Probably slower and with more respect for existing tech. But hey, now we have npm, so who cares anymore? :-)

Disrespect is part of progress, respectful humans are liable to blindness of flaws. Just as part of youthful creativity is disregard for what has come before.

It's a double-edged sword: ancestor-worship blocks progress, but throwing the baby out with the bathwater also blocks progress. Real fundamental progress comes from the tiny minority that avoids both.

Re: Be Aware of the Makefile Effect

#347

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…

That's effectively "make clean" just slightly more automated. Btw, what happens if you change CFLAGS? Does anything get compiled if no files have changed?
Post reply on HN