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

271–280 of 347 posts

Re: Be Aware of the Makefile Effect

#271

Post by johnnyanmac »

oblio wrote: post #247
wellbehaved wrote: post #243

Earlier quoted context omitted.

With that attitude how would the presently accepted languages/frameworks have come about?

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

Most languages are much older than we think. But early adoption is a key to geting to that point of when to "trust it". D isn't that much younger than C and its variants, and older than C#. But it never quite got that adoption to really push development to the point of C#

Re: Be Aware of the Makefile Effect

#272

Post by ezekiel68 »

I do write makefiles de novo (including in corporate settings). But I start "backwards" with the "clean" and "distclean" targets, then get a single basic debug build target working. From there, I find it relatively easy to expand to larger and more complex operations. Brick by brick.

Re: Be Aware of the Makefile Effect

#273

Post by jandrese »

Quekid5 wrote: post #244
IgorPartola wrote: post #234

Make and Makefiles are incredibly simple when they are not autogenerated by autoconf. If they are generated by autoconf, don’t modify them, they are a build artifact. But also, ditch autoconf if you can. In the broader sense: yes this effect is very real. You can fall to it or you can exploit it. How I exploit it: write a bit of code (or copy/paste it from somewhere). Use it in a project. Refine as needed. When start…

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: application.c $(HEADERS)

    jsonstuff.o: jsonstuff.c $(HEADERS)

    otherstuff.o: otherstuff.c $(HEADERS)

    clean:
            rm -f $(EXE) *.o
This isn't perfect as it causes a full project rebuild whenever a header is updated, but I've found it's easier to do this than to try to track header usage in files. Also, failing to rebuild something when a header updates is a quick way to drive yourself crazy in C, it's better to be conservative. It's easy enough that you can write it from memory in a minute or two and pretty flexible. There are no unit tests, no downloading and building of external resources, or anything fancy like that. Just basic make. It does parallelize if you pass -j to make.

Re: Be Aware of the Makefile Effect

#274

Post by Terr_ »

RHSeeger wrote: post #266
withinboredom wrote: post #255

Earlier quoted context omitted.

The problem with `git clean` is -X vs -x. -x (lowercase) removes EVERYTHING including .env files and other untracked files. -X (uppercase) removes only ignored files, but not untracked files. If there is a Makefile with a clean target, usually the first thing I do when I start is make it an alias for `git clean -X`. Usually, you want to keep your untracked files (they are usually experiments, debugging hooks, or what…

This. I have no urge to have git "clean" my project, because I'll lose a ton of files I have created locally. Rather, I want the project know what it creates when it builds and have the ability to clean/purge them. It's a never ending source of frustration for me that "gradlew clean" only cleans _some_ stuff, and there's no real "gradlew distclean".

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

Re: Be Aware of the Makefile Effect

#275

Post by scubbo »

lolinder wrote: post #214
foobarchu wrote: post #210

Earlier quoted context omitted.

For actual cargo cults, yes. Cargo Cult Development just used the name to invoke a comparison..when CCD is being practiced, devs are doing mystical steps because it's part of the incantation. They wouldn't keep doing them if the project then never worked. Your definition is extremely unlikely to ever be practiced, because those developers would be fired for never getting anything working, and so it's not really a hel…

Concrete examples of what I think actually counts as cargo culting: * Incorporating TDD because it's a "best practice". * Using Kubernetes because Google does it. * Moving onto AWS because it's what all the cool companies are doing. The key thing that makes cargo cult development a cargo cult is that it's practices and rituals adopted without any concrete theory for what a bit is supposed to do for you in your contex…

Right, yes, exactly this. Using a tool or process without full understanding of its operation, or how to use it in different ways, is not _ideal_ - but it's a different thing (similar! but different) from "doing something just because everyone else is doing it". A Makefile-copier might not know the full stack of concepts that undergird their working configuration - but they do know (in the "true justifiable knowledge" sense) that it _is_ a working configuration, and they know why they're adopting it.

Re: Be Aware of the Makefile Effect

#276

Post by stouset »

IgorPartola wrote: post #234

Make and Makefiles are incredibly simple when they are not autogenerated by autoconf. If they are generated by autoconf, don’t modify them, they are a build artifact. But also, ditch autoconf if you can. In the broader sense: yes this effect is very real. You can fall to it or you can exploit it. How I exploit it: write a bit of code (or copy/paste it from somewhere). Use it in a project. Refine as needed. When start…

They are also extremely limited. Timestamp-based freshness is often broken by modern VCSes. Git doesn’t record timestamps internally, so files can (and often do) have their mtime updated even when their contents are the same, causing unnecessary rebuilds.

They also are utterly unable to handle many modern tools whose inputs and/or outputs are entire directories or whose output names are not knowable in advance of running the tool.

I love make. I have put it to good use in spite of its shortcomings and know all the workarounds for them, and the workarounds for the workarounds, and the workarounds for those workarounds. Making a correct Makefile when you end up with tools that don’t perfectly fit into its expectations escalates rapidly in difficulty and complexity.

Re: Be Aware of the Makefile Effect

#277

Post by scubbo »

foobarchu wrote: post #210
scubbo wrote: post #207

Earlier quoted context omitted.

> a cargo cult works But...it doesn't? That's the whole definitional point of it. If action A _does_ lead to outcome B, then "if we do A, then B will happen" is not a cargo cult perspective, it's just fact.

For actual cargo cults, yes. Cargo Cult Development just used the name to invoke a comparison..when CCD is being practiced, devs are doing mystical steps because it's part of the incantation. They wouldn't keep doing them if the project then never worked. Your definition is extremely unlikely to ever be practiced, because those developers would be fired for never getting anything working, and so it's not really a hel…

Hmm, fair, my definition certainly doesn't apply to CCD ("we do it because Google does it") - but I still maintain (as a child commenter elaborates) that there's a difference between "the reason I'm doing this is because other people do it" and "the reason I'm doing this is to achieve my given aim. I don't the exact functionality by which this leads to the aim being achieved, and I might not be able to modify this to achieve other aims - but I do know that it will get me where I want to go".

Neither is ideal - but, the latter is much less harmful IMO.

Re: Be Aware of the Makefile Effect

#278

Post by PaulHoule »

kragen wrote: post #167
silver_silver wrote: post #109

Earlier quoted context omitted.

Yes and they’re far less efficient and require far more maintenance than an equivalent electric or even diesel engine, where equivalent power is even possible

Steam engines currently power most of the world's electrical grid. The main reason for this is that, completely contrary to what you said, they are more efficient and more reliable than diesel engines. (Electric motors of course are not a heat engine at all and so are not comparable.) Steam engines used to be very inefficient, in part because the underlying thermodynamic principles were not understood, but also becau…

Steam engines are thoroughly obsolete in the developed world where there are natural gas pipeline networks.

People quit building coal burning power plants in North America at the same time they quit burning nuclear power plants for the same reason. The power density difference between gas turbines and steam turbines is enough that the capital cost difference is huge. It would be hard to afford steam turbines if the heat was free.

Granted people have been building pulverized coal burning power plants in places like China where they'd have to run efficient power plants on super-expensive LNG. They thought in the 1970s it might be cheaper to gasify coal and burn it in a gas turbine but it's one of those technologies that "just doesn't work".

Nuclear isn't going to be affordable unless they can perfect something like

https://www.powermag.com/what-are-supercritical-co2-power-cy...

If you count the cost of the steam turbine plus the steam generators plus the civil works to enclose those, nuclear just can't be competitive.

Re: Be Aware of the Makefile Effect

#279

Post by bluGill »

kragen wrote: post #168
icameron wrote: post #133

Earlier quoted context omitted.

That’s an insightful comment, but there is a whole universe of programmers who never have to directly work in C/C++ and are productive in safe languages that can’t segfault usually. Admittedly we are a little jealous of those elite bitcrashers who unlock the unbridled power of the computer with C++… but yeah a lot of day jobs pay the bills with C#, JavaScript, or Python and are considered programmers by the rest of t…

Yeah, I write most things in Python or JavaScript because it's much more practical.

Both have strong limits for writing complex code. Typescript is one attempt of an answer because bad as javascript is for large programs the web forces it. I prefer a million lines of c++ to 100k lines of python - but if 5k lines of python sill do them c++ is way too much overhead. (rust likely plays better than c++ for large problems from scratch but most large probles have existing answers and throwing something else in would be hard)

Re: Be Aware of the Makefile Effect

#280

Post by bluGill »

foobarchu wrote: post #213
kragen wrote: post #101

Earlier quoted context omitted.

Steam engines predate the understanding of not just the crystalline structure of steel but even the basics of thermodynamics by quite a few decades.

I don't consider that an equal comparison. Obviously an engineer can never be omniscient and know things nobody else knows either. They can, and should, have an understanding of what they work with based on available state of the art, though. If the steam engine was invented after those discoveries about steel, I would certainly hope it would be factored into the design (and perhaps used to make those early steam eng…

A lot of material science was developed to make cannons not explode - that them went into making steam engines possible. The early steam engines introduced their own needed study of efficiency-
Post reply on HN